Spreadsheet-based software application development

ABSTRACT

Aspects described herein may be used with local spreadsheet applications, web, and/or cloud-based spreadsheet solutions, to create complex custom software applications. Spreadsheets themselves lack the conceptual framework to be used as a platform tool to build custom or complex software applications. Using the methods and systems described herein using low-code/no-code techniques, a designer can create custom and/or complex software applications using one or more spreadsheets as the underlying blueprints for the software application. The resultant software application may be static/read-only, or may be interactive to allow users to dynamically add, delete, edit, or otherwise amend application data, e.g., via one or more online web pages or via a mobile application. Data transfer may be one-way or bi-directional between the blueprint spreadsheets and the resultant software application, thereby allowing amended data to be transferred from the software application back into spreadsheet form.

CROSS-REFERENCE TO RELATED CASES

This application is a continuation of application Ser. No. 17/102,993,filed on Nov. 24, 2020, entitled, “Spreadsheet-Based SoftwareApplication Development,” which is a continuation of application Ser.No. 16/254,155, filed on Jan. 22, 2019, entitled, “Spreadsheet-BasedSoftware Application Development,” which is a continuation ofapplication Ser. No. 15/455,909, filed Mar. 10, 2017, entitled“Spreadsheet-Based Software Application Development,” which claimspriority to U.S. Provisional Application No. 62/429,749, filed Dec. 3,2016, entitled “Spreadsheet-Based Software Application Development,”herein incorporated by reference in their entirety for all purposes.

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent file or records, but otherwise reserves all copyrightrights whatsoever.

FIELD

Aspects described herein generally relate to application and softwaredevelopment for computers and computer networks. More specifically,aspects described herein provide systems and methods for low-code andno-code software development of custom, complex software such asinteractive web applications, among others.

BACKGROUND

Software development can be a difficult and time consuming process.Specialized training and knowledge are generally required, and oftenyears of experience is needed, before an individual can develop acomplex and/or custom software application. Those who do not possessthese skills must employ a software developer or software developmentcompany to do the software development, often at great expense. Inaddition, once the software development process has started, it can takeweeks, months, or even years to develop custom and/or complex software.

Developing custom software applications to be used online or with mobiledevices generally involves programming in a high-level programminglanguage such as C# or Java. The more flexibility and power a softwareapplication has, the more time consuming and cost prohibitive it becomesfor many organizations to fund or build. Even when software applicationdevelopers utilize pre-built components to cost share among severalclients, many projects remain time consuming to build due to uniquerequirements of each organization.

In some cases, software applications can be purchased off-the-shelf, butthen an organization is limited to the features of the off-the-shelfproduct. Customization is often difficult, time consuming, and/orexpensive, just as original software development would be.

Based on their incredibly powerful business analysis, record keeping andorganizational capabilities, spreadsheets are now ubiquitous inbusiness. Spreadsheets are used in business more than any category ofsoftware, except perhaps word processors. However, spreadsheetsthemselves lack the conceptual framework to be used as a platform toolto build software applications. At best, existing spreadsheet softwaremay allow a user to include program code to perform one or more customfunctions. However, that program code still must be written in anadvanced language, such as Visual Basic, which again requires advancedprogramming skill, capabilities, and resources.

BRIEF SUMMARY

The following presents a simplified summary of various aspects describedherein. This summary is not an extensive overview, and is not intendedto identify key or critical elements or to delineate the scope of theclaims. The following summary merely presents some concepts in asimplified form as an introductory prelude to the more detaileddescription provided below.

Spreadsheets are a popular tool and unique conceptual model fornon-technical users to perform tasks such as calculations and printingreports. Spreadsheets are often used in two ways: a table where each rowis a record, or having each record comprise an entire sheet or file.While spreadsheets and spreadsheet applications themselves lack theconceptual framework to act as a platform tool to build softwareapplications, aspects described herein include tools and functionalityoperative to automatically generate complex interactive software and/orweb applications using one or more spreadsheets as the underlyingblueprints for such a system. Such a tools and functionality, or methodsand/or systems configured with one or more tools and/or functionalitydescribed herein, may also be referred to as a webifier, webifiersystem, webifier software, or the like.

To overcome limitations in the prior art as described above, and toovercome other limitations that will be apparent upon reading andunderstanding the present specification, one or more aspects describedherein are directed to facilitating the creation of interactive webapplications based on data and formatting templates included in aspreadsheet.

A first aspect described herein provides methods, systems, and computerreadable media for generating an interactive web application comprisingat least one web page. Techniques described herein may compriseanalyzing a spreadsheet to identify one or more data sources each havingone or more data records, and to identify one or more user interfacetemplates each comprising a data format for one or more of the datasources. The spreadsheet may comprise a plurality of worksheets (alsoreferred to herein as simply “sheets”), and a data source may compriseat least a portion of a first spreadsheet while a user interfacetemplate may comprise at least a portion of a second spreadsheet. A webdata store may be generated based on extracting data records from thedata sources identified within the spreadsheet and storing the datarecords in the web data store. The system may generate a particular webpage of the interactive web application based on the extracted datarecords of the web data store, and the particular web page may comprisedata records and/or references to data records identified by andformatted according to one or more user interface templatescorresponding to the particular web page. The system may generate apresentation of the particular web page responsive to a request for apage. Further, the system may update the web data store responsive toreceiving user input via the web application.

The user interface templates may define and/or comprise data formats forcorresponding data sources and/or records, such as font formats, cellsize, and/or any other suitable display formatting. In some embodiments,the user interface templates may define one or more data restrictionsassociated with a data source. Such data restrictions may be used toselect data records from the data source. Alternatively and/oradditionally, the user interface templates may define one or more inputvalidation controls associated with a data source. The system mayevaluate user input against an input validation control as part of or inaddition to updating the web data store. According to some aspects, theone or more user interface templates may be stored in separateworksheets from the one or more data sources. In other aspects, the oneor more user interface templates may be stored in the same worksheet asthe one or more data sources.

According to some aspects, the system may update the interactive webapplication based on identifying one or more changes to at least onedata format and/or data record in the spreadsheet. Changes to dataformats in user interface templates may be implemented in theinteractive web application without affecting the web data store.Changes to content of data records may automatically be reflected inpages of the interactive web application. The system may operateautomatically to detect and/or analyze changes made to data recordsand/or data formats in the spreadsheet. According to some aspects, thesystem may update the underlying spreadsheet based on updates made tothe web data store. Additionally and/or alternatively, the system mayupdate the web data store based on changes made to data records in thespreadsheet. Similarly, the system may update the interactive webapplication based on changes made to data formats in user interfacetemplates of the spreadsheet.

According to some aspects, the system may implement permission controlsto limit the ability of users to view and/or modify data stored in theweb data store and/or spreadsheet. Security permissions for users may bedefined in the spreadsheet, such as in the one or more user interfacetemplates. Security permissions may be defined using native formulas ofa spreadsheet application associated with the spreadsheet. Additionallyand/or alternatively, security permissions may be retrieved from sourcesother than the spreadsheet such as an administrative policy server. Thesystem may prevent modification of the web data store by a first userhaving first security permissions. The system may allow modification ofthe web data store responsive to input received from a second userhaving second security permissions.

The spreadsheet may be generated using spreadsheet application software.For example, in some embodiments the spreadsheet may be generated usingMICROSOFT EXCEL. The spreadsheet may comprise a data file and/orcollection of files that conform to any conventional spreadsheet dataformat. For example, the spreadsheet may conform to the XLSX, MS-XLSand/or MS-XLSB binary data formats utilized in MICROSOFT EXCEL. In someembodiments, the generated web data store may comprise the spreadsheet,or vice versa.

According to some aspects, the interactive web application may generateinput and/or output web pages based on the data records and/or userinterface templates. In some embodiments, the system may generate a webinput form based on the data sources identified in one or more userinterface templates and may receive the user input to modify one or morerecords via the web input form. The system may generate a data outputweb page for outputting data from the web data store based on a firstuser interface template, and may generate a data editing web page usableto edit data in the web data store based on a second user interfacetemplate. In some embodiments, generating a particular web page maycomprise selecting a user interface template corresponding to a clientdevice characteristic associated with the particular web page.

According to another aspect or embodiment, a webifier system may beconfigured to generate an interactive web application comprising atleast one web page by determining one or more data sources within a (ormultiple) spreadsheet, each data source having zero or more datarecords, wherein the data sources comprise a first portion of thespreadsheet; determining one or more user interface templates fromwithin the spreadsheet, each user interface template comprising a dataformat for one or more of the data sources, wherein the user interfacetemplates comprise a second portion of the spreadsheet; generating a webdata store comprising data records from the data sources identifiedwithin the spreadsheet; generating a particular web page of theinteractive web application based on one or more user interfacetemplates corresponding to the particular web page, wherein theparticular web page references one or more data sources identified basedon the one or more user interface templates corresponding to theparticular web page; responsive to a request for a presentation of theparticular web page of the interactive web application, generating thepresentation of the particular web page including one or more datarecords identified by and formatted according to the one or more userinterface templates corresponding to the particular web page; andupdating the web data store responsive to receiving user input via a webpage of the interactive web application generated based on thespreadsheet.

In some aspects, any combination of the following may be included withinor by a webifier system: the web page of the interactive web applicationgenerated based on the spreadsheet is the particular web page; thespreadsheet comprises a plurality of worksheets, and the first portionof the spreadsheet is on a different worksheet than the second portionof the spreadsheet; the spreadsheet comprises a plurality of worksheets,and the one or more user interface templates are stored in the sameworksheet as the one or more data sources; at least one data format ofthe user interface templates comprises a font format of a correspondingdata source; at least one data format of the user interface templates isbased on a cell size of a corresponding data source; the method mayfurther include updating the spreadsheet based on updating the web datastore; the method may further include analyzing the spreadsheet toidentify one or more changes to at least one data format associated withthe one or more user interface templates, and updating the interactiveweb application based on the changed data formats without affecting theweb data store; the method may further include analyzing the spreadsheetto identify one or more changes made to the data records of the one ormore data sources, and updating the web data store based on the changeddata records (where such modification may occur automatically, atintervals, based on user input, etc.); the method may further includeanalyzing the spreadsheet to identify one or more changes made to atleast one data record associated with the one or more data sources, andupdating the web data store based on the changed data records (wheresuch modification may further occur automatically, at intervals, basedon user input, etc.)

In one or more embodiments, and in combination with any otherembodiment, a webifier system may include security controls to preventmodification of the web data store by a first user having first securitypermissions, and allow modification of the web data store responsive toinput received from a second user having second security permissions.The first and second security permissions may be determined based on theone or more user interface templates. A security permission mayoptionally be defined by a formula native to a spreadsheet applicationthat generated the spreadsheet.

In one or more embodiments, and in combination with any otherembodiment, the spreadsheet may comprise the generated web data store,or the web data store may be separate from the spreadsheet.Identification or generation of the web data store may include storing arecord of the applicable spreadsheet(s) or portions thereof as storingthe applicable data.

In one or more embodiments, and in combination with any otherembodiment, a webifier system may use spreadsheets that conform to theXLSX, MS-XLS binary data format or MS-XLSB binary data format.

In one or more embodiments, and in combination with any otherembodiment, a webifier system may, after generating the web data store,subsequently update the web data store based on one or more changes madeto one or more data records in the spreadsheet.

In one or more embodiments, and in combination with any otherembodiment, a webifier system may, after generating the particular webpage, update the particular web page based on one or more changes madeto one or more user interface templates in the spreadsheet.

In one or more embodiments, and in combination with any otherembodiment, a webifier system may include at least one user interfacetemplate that identifies one or more data restrictions associated with adata source, and the system may generate the presentation of theparticular webpage based on selecting data records that satisfy the oneor more data restrictions. The one or more data restrictions mayoptionally comprise a user-level security restriction identified in thespreadsheet. Optionally, at least one of the one or more datarestrictions may be defined by a formula native to a spreadsheetapplication associated with the spreadsheet.

In one or more embodiments, and in combination with any otherembodiment, a webifier system may include at least one user interfacetemplate that identifies one or more input validation rules associatedwith a particular data source, and the system may further evaluate theuser input against the one or more input validation rules. Optionally,when the web data store identifies one or more input validation rulesassociated with the particular web page, and system may evaluate theuser input against the one or more input validation rules.

In one or more embodiments, and in combination with any otherembodiment, a webifier system may receive user input via the webapplication, and the system may generate a web input form based on thedata sources identified in one or more user interface templates, andreceive the user input via the web input form.

In one or more embodiments, and in combination with any otherembodiment, the interactive web application may generate a data outputweb page for outputting data from the web data store based on a firstuser interface template, and generate a data editing web page usable toedit data in the web data store based on a second user interfacetemplate.

In one or more embodiments, and in combination with any otherembodiment, a webifier system may generate the particular web page byselecting a user interface template corresponding to a client devicecharacteristic associated with the particular web page, e.g., to modifypages particular to mobile devices, among others.

According to another aspect, a webifier system may include one or moreprocessors, and memory storing instructions that, when executed by theone or more processors, cause the system to generate an interactivesoftware application (e.g., a web application). The webifier system mayobtain, based on evaluating a spreadsheet, one or more data sourceswithin the spreadsheet each having one or more data records, wherein thedata sources comprise at least a portion of a first worksheet of thespreadsheet. The system may obtain, based on evaluating the spreadsheet,one or more user interface templates within the spreadsheet eachcomprising a data format for one or more of the data sources, whereinthe user interface templates comprise at least a portion of a secondworksheet of the spreadsheet. The system may optionally generate a webdata store by extracting data records from the data sources identifiedwithin the spreadsheet and storing the data records in the web datastore, or the system may use the spreadsheet as a web data store (inthis or any other embodiment). The system may generate a particular webpage of the interactive software application based the extracted datarecords of the web data store, wherein the particular web page comprisesreferences to data records identified based on and formatted accordingto one or more user interface templates corresponding to the particularweb page. Responsive to a request for a presentation of the particularweb page of the interactive software application, the system maygenerate the presentation of the particular web page. The system mayalso update the web data store responsive to receiving user input viathe interactive software application.

In one or more embodiments, and in combination with any otherembodiment, a webifier system may include at least one user interfacetemplate that identifies one or more data restrictions associated with adata source. The instructions, when executed by the one or moreprocessors, may further cause the system to generate the presentation ofthe particular webpage based on selecting data records that satisfy theone or more data restrictions.

According to another aspect or embodiment, a webifier system maygenerate an interactive web application. The webifier system may obtain,based on evaluating a spreadsheet, one or more data sources within thespreadsheet each having zero or more data records, wherein the datasources comprise at least a portion of a first worksheet of thespreadsheet. The system may obtain, based on evaluating the spreadsheet,one or more user interface templates within the spreadsheet eachcomprising a data format for one or more of the data sources, whereinthe user interface templates comprise at least a portion of a secondworksheet of the spreadsheet. The system may generate a web data storecomprising data records from the data sources identified within thespreadsheet. The system may generate a particular web page of theinteractive web application based on one or more user interfacetemplates corresponding to the particular web page, wherein theparticular web page comprises references to at least one data source ofthe data sources and formatting based on the one or more user interfacetemplates corresponding to the particular web page. The system may,responsive to a request for a presentation of the particular web page ofthe interactive web application, generate the presentation of theparticular web page including one or more data records associated withthe at least one data source and formatted according to the one or moreuser interface templates corresponding to the particular web page. Thesystem may update the web data store responsive to receiving user inputvia the interactive web application. The first worksheet may be the sameworksheet or a different worksheet than the second worksheet.

According to another aspect, any one or more embodiments may furtherinclude generating a spreadsheet user interface presenting at least aportion of the spreadsheet for display, wherein the spreadsheet userinterface comprises one or more controls allowing a user to identify oneor more data sources within the spreadsheet and identify one or moreuser interface templates within the spreadsheet. Generating a particularweb page of the interactive web application may then be performed inresponse to receiving user input via the one or more controlsidentifying at least the one or more user interface templatescorresponding to the particular web page.

In one or more embodiments, and in combination with any otherembodiment, the spreadsheet user interface comprises a two-dimensionalarrangement of cells. Cells of the spreadsheet user interface maysupport numeric values, text values, and formulas. Cell formulas in thespreadsheet user interface may allow the user to specify mathcalculations. Cell formulas in the spreadsheet user interface may allowreference to multiple other cells. Cell formulas in the spreadsheet userinterface may also support mathematical and string manipulationfunctions.

Optionally, cell formulas in the spreadsheet user interface may supportreferences to named functions; cells of the spreadsheet user interfacemay support heterogeneous formats and formulas within a given row, agiven column, or a given region of the spreadsheet user interface;and/or cell formulas in the spreadsheet user interface may supportreferences to other cells containing other formulas, numeric values, ortext values.

In some aspects, the spreadsheet user interface provides a visualediting user interface allowing users to edit and format cells of thespreadsheet user interface, and the visual editing user interface mayprovide visual feedback to users based on format changes, formulachanges, and format evaluation values and/or rules.

In some aspects, the spreadsheet user interface may allow a user toindicate that contents of a single cell may visually span acrossmultiple rows or multiple columns without affecting whether the contentsof other cells may visually span across multiple rows or multiplecolumns.

In some aspects, the spreadsheet user interface may allow users toselect cells and move cell contents to other cells by interacting withthem to highlight a single cell or range of cells.

In some aspects, the spreadsheet user interface may allow users toselect one or more cells in order to automatically insert a reference tothose cells into a formula of a cell currently being edited.

In some embodiments user input may comprise a signature and metadataassociated with the signature.

In some aspects, a webifier system may generate mobile softwareapplications and/or content for display by a mobile device or mobileapplication. The webifier system may determine one or more data sourceswithin a spreadsheet, each data source having one or more data records.The webifier system may determine one or more user interface templateswithin the spreadsheet, each template comprising a data format for oneor more of the data sources. The webifier system may optionally generatea data store comprising data records from the data sources identifiedwithin the spreadsheet, or may use the spreadsheet as the data store.The webifier system may generate a plurality of versions of a particularweb page based on one or more user interface templates corresponding tothe particular web page, wherein the particular web page references oneor more data sources identified based on the one or more user interfacetemplates corresponding to the particular web page, and wherein at leastone of the versions of the particular web page is a mobile version basedon one or more user interface templates associated with mobile clients.The webifier system may receive a request for a presentation of theparticular web page of the interactive web application from a mobiledevice, e.g., where the request identifies a user device as a mobileclient or device. Responsive to the request, the webifier system maygenerate the presentation of the mobile version of the particular webpage including one or more data records identified by and formattedaccording to the one or more user interface templates corresponding tothe particular web page and the one or more user interface templatesassociated with mobile clients. The webifier system may update the datastore responsive to receiving user input from the mobile device.

According to another aspect, and in combination with any other aspect orembodiment, a webifier system may generate a spreadsheet user interfacepresenting data records of a data file, wherein the spreadsheet userinterface displays the data records in a row and column tabular formatcomprising a plurality of cells, and wherein the spreadsheet userinterface allows users to define formulas to calculate the value of afirst cell of the spreadsheet user interface based on a value of asecond cell of the spreadsheet user interface.

The spreadsheet user interface may include a two-dimensional arrangementof cells supporting numeric values, text values, and formulas. Cellformulas in the spreadsheet user interface allow the user to specifymath calculations, reference to multiple other cells, references tonamed functions (and/or regions), and/or mathematical and stringmanipulation functions.

In some aspects, the cells of the spreadsheet user interface may supportheterogeneous formats within a given row, a given column, or a givenregion of the spreadsheet user interface and/or references to othercells containing other formulas, numeric values, or text values.

In some aspects, the spreadsheet user interface provides a visualediting user interface allowing users to edit and format cells of thespreadsheet user interface, and the visual editing user interface mayprovide visual feedback to users based on format changes, formulachanges, and format evaluation values.

In some aspects, the spreadsheet user interface may allow a user toindicate that contents of a single cell may visually span acrossmultiple rows or multiple columns without affecting whether the contentsof other cells may visually span across multiple rows or multiplecolumns.

In some aspects, the spreadsheet user interface may allow users toselect cells and move cell contents to other cells by interacting withthem to highlight a single cell or range of cells, and/or allow users toselect one or more cells in order to automatically insert a reference tothose cells into a formula of a cell currently being edited.

According to another aspect or embodiment, a webifier system maygenerate an interaction software application. The webifier system mayanalyze (or process, determine, obtain, or the like) a (or multiple)spreadsheet to identify a one or more data sources each having one ormore data records. The webifier system may analyze (or process,determine, obtain, or the like) the spreadsheet(s) to identify one ormore user interface templates each comprising a data format for one ormore data sources. The webifier system may optionally generate a webdata store by extracting data records from the data sources identifiedwithin the spreadsheet, and store the data records in the web datastore, or the webifier system may use the spreadsheet(s) as the web datastore. Responsive to a request to create a particular web page withinthe interactive software application, the webifier system may identifyone or more user interface templates corresponding to the particular webpage, identify one or more data sources corresponding to the particularweb page, and generate the particular web page based on the identifiedone or more user interface templates and based on the one or moreidentified data sources. The webifier system may, responsive to arequest from a client device for the particular web page, retrieve oneor more data records from the web data store based on the one or moreidentified data sources, and serve the particular web page including theone more retrieved data records formatted according to the one or moreidentified user interface templates. The webifier system may update theweb data store (or spreadsheet, as applicable) responsive to receivinguser input via the web application.

According to another aspect or embodiment, a webifier system maygenerate an interactive web application. The webifier system may analyze(or process, determine, obtain, etc.) a spreadsheet (or multiplespreadsheets) to identify a one or more data sources each having one ormore data records. The webifier system may also identify within thespreadsheet(s) one or more user interface templates each comprising adata format for one or more data sources. The webifier system mayoptionally generate a web data store by extracting data records from thedata sources identified within the spreadsheet, and storing the datarecords in the web data store, or the webifier system may use thespreadsheet(s) as the web data store. The webifier system, responsive toa first request for a particular web page within the interactive webapplication, may compose the particular web page using the data recordsfrom the web data store (or spreadsheet(s)), where the data records areidentified by and formatted according to the one or more user interfacetemplates corresponding to the particular web page. The webifier systemmay analyze the spreadsheet to identify one or more changes made aftergenerating the web data store, and update the interactive webapplication using the one or more changes made to the spreadsheet.Responsive to a second request for the particular web page, the webifiersystem may compose the particular web page incorporating the one or morechanges made to the spreadsheet.

In some aspects, the one or more changes made to the spreadsheet mayinclude edits to the user interface templates, and composing theparticular web page incorporating the one or more changes made to thespreadsheet includes generating the particular web page incorporatingthe edits to the user interface templates, without altering the datarecords.

In some aspects, where the one or more changes made to the spreadsheetinclude edits to the data records, then composing the particular webpage incorporating the one or more changes made to the spreadsheet mayinclude generating the particular web page incorporating the edits tothe data records without altering the user interface templates.

It should be noted that any feature described above may be used with anyparticular aspect or embodiment. Many combinations, modifications, oralterations to the features of the above embodiments and those describedherein will be readily apparent to the skilled person and are intendedto form part of the invention. Any of the features describedspecifically relating to one embodiment or example may be used in anyother embodiment.

BRIEF DESCRIPTION OF THE DRAWINGS

The patent or application file contains at least one drawing executed incolor. Copies of this patent or patent application publication withcolor drawings will be provided by the Office upon request and paymentof the necessary fee.

A more complete understanding of aspects described herein and theadvantages thereof may be acquired by referring to the followingdescription in consideration of the accompanying drawings, in which likereference numbers indicate like features, and wherein:

FIG. 1 illustrates a system architecture that may be used with one ormore illustrative aspects described herein.

FIG. 2 is a method of performing rapid software application developmentaccording to one or more illustrative aspects described herein.

FIGS. 3A and 3B show illustrative software system architectures thateach may be used to implement one or more illustrative aspects describedherein.

FIGS. 4-98 are screenshots of a spreadsheet-based software applicationdevelopment system according to one or more illustrative aspectsdescribed herein.

DETAILED DESCRIPTION

As a general introduction, aspects described herein may providelow-code/no-code methods and systems operative to automatically generatecomplex software applications using one or more spreadsheets as theunderlying blueprints for the software application. According to someaspects, the resultant software application may be static (read-only),or may be interactive (read/write) to allow users to dynamically add,delete, edit, or otherwise amend application data, e.g., via one or moreonline web pages. Data transfer may be one-way or bi-directional betweenthe blueprint spreadsheets and the resultant software application, insome embodiments, thereby allowing amended data to be transferred to andfrom the software application and the spreadsheet form, either back tothe original spreadsheet(s) or new spreadsheet(s).

A spreadsheet as used herein refers to the logical arrangement of datafor presentation to a user, regardless of the form that the data isstored. Spreadsheet software applications (e.g., MICROSOFT EXCEL, APPLENUMBERS, and GNOME GNUMERIC) are a well-known type of software thatallow users to create and edit spreadsheets in which data is arranged inrows and columns of a grid and can be manipulated and used incalculations. A spreadsheet software application may also refer to aninteractive computer application for organization, analysis and storageof data in tabular form, either locally on a computer or usable in acloud-based architecture. Spreadsheets have also been referred to ascomputerized simulations of paper accounting worksheets. Spreadsheetsoftware applications generally operate on data entered in cells of aspreadsheet, where each cell of the spreadsheet may contain numericdata, text data, or the results of formulas that automatically calculateand display a value based on math equations, the contents of one or moreother cells, or even externally linked data. According to oneillustrative aspect, a spreadsheet may be defined as a data file usableby a particular spreadsheet software application. One or morespreadsheet documents or data files may comprise multiple individualand/or separate spreadsheets (e.g., worksheets, tabs), which may or maynot reference data in other spreadsheets/worksheets from the same and/ordifferent files. In one respect, spreadsheets differ from databasesinsofar as databases typically require data to be stored in one or moreindexed tables, whereas spreadsheets support both database andnon-database uses. Illustrative aspects described herein may relate tolocal spreadsheet application software. However, in other illustrativeaspects a spreadsheet may be presented to a user via a user interface ofa cloud-based system, presenting the user with spreadsheet functionalityand features through a web browser or other networked user interface,irrespective of the back-end system architecture providing thefunctionality or the format in which the data is ultimately stored(e.g., GOOGLE SHEETS, MICROSOFT OFFICE ONLINE, EditGrid, ZK Spreadsheet,Sheetster, Smartsheet, DHTMLX Spreadsheet, Webix, eXpresso, ThinkFreeCell). Aspects described herein may be applied to both local spreadsheetapplication software implementations as well as cloud-based spreadsheetimplementations, or any other spreadsheet implementation.

Spreadsheet applications typically have in common a characteristic twodimensional arrangement of cells in rows and columns when viewed by auser, potentially any additional dimensions represented as additionaltwo dimensional arrangements, cells that are able to contain a numericvalue or text value or formula input by a user, and cell formulas thatallow the user to specify math calculations and/or to reference multipleother cells by the cells' position within the two dimensionalarrangement. Some modern, complex, spreadsheet applications, includingMICROSOFT EXCEL and GOOGLE SHEETS, sometimes have in common one or moreof the further characteristics of cell formulas that can be mathematicalor string manipulation formulas, cell formulas that can reference othercell's that contain other formulas or numeric values or text values, theability for the user to format cells in a visual WYSIWYG (“What You SeeIs What You Get”) editor, immediate visual feedback to the user offormat changes and formula changes and formula evaluation resultantvalues, cell formulas that can call named functions such as “sum( )” or“concatenate( )”, cell references that can be a single cell or a rangeof cells such as “A1:B10” or “A1:A10,C1:C10”, cell ranges that can beassigned a text alias to be used in other cell references, a userinterface that allows the user to select cells and move cell contents toother cells by interacting with them to first highlight a single cell orrange of cells, a user interface that allows the user to select one ormore cells in order to automatically insert a reference to those cellsinto the formula of the cell currently being edited, allowing the userto specify that a single cell or single cell's contents may visuallyspan across multiple rows and/or columns without requiring other cellsto span as well, minimal or no restrictions on the logical orientationof data such that the rows and columns are interchangeable and datacould therefore be input in a pivoted orientation, cells where theformat and values and formulas do not need to be consistent across anentire row or entire column or entire region of cells, and columns thatcan be changed in width as a group. Not all these features are requiredfor an application to be a spreadsheet software application.

In the following description of the various embodiments, reference ismade to the accompanying drawings, which form a part hereof, and inwhich is shown by way of illustration various embodiments in whichaspects described herein may be practiced. It is to be understood thatother embodiments may be utilized and structural and functionalmodifications may be made without departing from the scope of thedescribed aspects and embodiments. Aspects described herein are capableof other embodiments and of being practiced or being carried out invarious ways. Also, it is to be understood that the phraseology andterminology used herein are for the purpose of description and shouldnot be regarded as limiting. Rather, the phrases and terms used hereinare to be given their broadest interpretation and meaning. The use of“including” and “comprising” and variations thereof is meant toencompass the items listed thereafter and equivalents thereof as well asadditional items and equivalents thereof. The use of the terms“mounted,” “connected,” “coupled,” “positioned,” “engaged” and similarterms, is meant to include both direct and indirect mounting,connecting, coupling, positioning and engaging.

FIG. 1 illustrates one example of a network architecture and dataprocessing devices that may be used to implement one or moreillustrative aspects described herein. Various network nodes 103, 105,107, and 109 may be interconnected via a wide area network (WAN) 101,such as the Internet. Other networks may also or alternatively be used,including private intranets, corporate networks, LANs, wirelessnetworks, personal networks (PAN), and the like. Network 101 is forillustration purposes and may be replaced with fewer or additionalcomputer networks. A local area network (LAN) may have one or more ofany known LAN topology and may use one or more of a variety of differentprotocols, such as Ethernet. Devices 103, 105, 107, 109 and otherdevices (not shown) may be connected to one or more of the networks viatwisted pair wires, coaxial cable, fiber optics, radio waves or othercommunication media.

The term “network” as used herein and depicted in the drawings refersnot only to systems in which remote storage devices are coupled togethervia one or more communication paths, but also to stand-alone devicesthat may be coupled, from time to time, to such systems that havestorage capability. Consequently, the term “network” includes not only a“physical network” but also a “content network,” which is comprised ofthe data—attributable to a single entity—which resides across allphysical networks, e.g., using a storage area network (SAN, not shown).

The components may include a data server 103, web server 105, and clientcomputers 107, 109. Data server 103 provides overall access, control andadministration of databases and control software for performing one ormore illustrative aspects described herein. Data server 103 may beconnected to web server 105 through which users interact with and obtaindata as requested. Alternatively, data server 103 may act as a webserver itself and be directly connected to the Internet. Data server 103may be connected to web server 105 through the network 101 (e.g., theInternet), via direct or indirect connection, or via some other network.Users may interact with the data server 103 and/or web server 105 usingremote computers 107, 109, e.g., using a web browser. Client computers107, 109 may be used in concert with data server 103 to access datastored therein, or may be used for other purposes. For example, fromclient device 107 a user may access web server 105 using an Internetbrowser, as is known in the art, or by executing a software applicationthat communicates with web server 105 and/or data server 103 over acomputer network (such as the Internet).

Servers and applications may be combined on the same physical machines,and retain separate virtual or logical addresses, or may reside onseparate physical machines. FIG. 1 illustrates just one example of anetwork architecture that may be used, and the specific networkarchitecture and data processing devices used may vary, and aresecondary to the functionality that they provide, as further describedherein. For example, services provided by web server 105 and data server103 may be combined on a single server.

Each component 103, 105, 107, 109 may be any type of known computer,server, or other data processing device. Data server 103, e.g., mayinclude a processor 111 controlling overall operation of the rate server103. Data server 103 may further include RAM 113, ROM 115, networkinterface 117, input/output interfaces 119 (e.g., keyboard, mouse,display, printer, etc.), and memory 121. I/O 119 may include a varietyof interface units and drives for reading, writing, displaying, and/orprinting data or files. Memory 121 may further store operating systemsoftware 123 for controlling overall operation of the data processingdevice 103, webifier control logic 125 for instructing data server 103to perform one or more aspects described herein, and other applicationsoftware 127 providing secondary, support, and/or other functionalitywhich may be used in conjunction with other aspects described herein,e.g., a spreadsheet software application. The webifier control logic mayalso be referred to herein as data server software, webifier system,webifier software, webifier plugin, or simply webifier. Functionality ofthe data server software may refer to operations or decisions madeautomatically based on rules coded into the control logic, made manuallyby a user providing input into the system, and/or a combination ofautomatic processing based on user input (e.g., queries, data updates,etc.).

Memory 121 may also store data used in performance of one or moreaspects described herein, including first data 129 (e.g., a spreadsheetdocument or file) and second data 131 (e.g., web data store, as furtherdescribed below). Devices 105, 107, 109 may have similar or differentarchitecture as described with respect to device 103. The functionalityof data processing device 103 (or device 105, 107, 109) as describedherein may be spread across multiple data processing devices, forexample, to distribute processing load across multiple computers, tosegregate transactions based on geographic location, user access level,quality of service (QoS), etc.

One or more aspects described herein may be embodied in computer-usableor readable data and/or computer-executable instructions, such as in oneor more program modules, executed by one or more computers or otherdevices as described herein. Generally, program modules includeroutines, programs, objects, components, data structures, etc. thatperform particular tasks or implement particular abstract data typeswhen executed by a processor in a computer or other device. The modulesmay be written in a source code programming language that issubsequently compiled for execution, or may be written in a scriptinglanguage such as (but not limited to) HTML or XML. The computerexecutable instructions may be stored on a tangible and non-transitorycomputer readable medium such as a hard disk, optical disk, removablestorage media, solid state memory, USB drive, RAM, etc. As will beappreciated by one of skill in the art, the functionality of the programmodules may be combined or distributed as desired in variousembodiments. In addition, the functionality may be embodied in whole orin part in firmware or hardware equivalents such as integrated circuits,field programmable gate arrays (FPGA), and the like. Particular datastructures may be used to more effectively implement one or moreaspects, and such data structures are contemplated within the scope ofcomputer executable instructions and computer-usable data describedherein.

According to one aspect, the webifier software may comprise a plug-in ormodule for use within an existing spreadsheet software application,e.g., a plugin within MICROSOFT EXCEL. Alternatively, the webifiersoftware may comprise a standalone software application that accepts asinput and generates as output one or more spreadsheet data files (e.g.,a MICROSOFT EXCEL.xls/.xlsx workbook file or any other spreadsheet datafile) and one or more software and/or web applications as describedherein. MICROSOFT EXCEL is used for illustrative purposes only. Theprinciples described herein are also applicable with other spreadsheetsoftware applications, and other spreadsheet storage formats, schemas,and/or standards. For example, COREL QUATTRO PRO, GOOGLE SHEETS,GNUMERIC, OPENOFFICE CALC, or any other spreadsheet software,application, and/or document format may be used. As noted above, aspectsherein may apply equally to both local spreadsheet application softwareimplementations as well as cloud-based spreadsheet implementations.

FIG. 2 shows an illustrative method of generating a softwareapplication, according to one or more aspects described herein.Initially, in step 201, a user (also referred to herein as a designer)may create and/or edit a spreadsheet using the spreadsheet softwareapplication of the designer's choice. The designer may set up and definea data source as a table where each row is a record of the data source,and/or define the data source as the spreadsheet file where eachindividual spreadsheet is a record of the data source. In this way thedesigner may define one or more data sources, and enter data records inthe one or more data sources.

In step 203 the webifier software, either automatically or responsive touser input, may analyze the spreadsheet to identify data sources anddata records. When responsive to user input, the webifier software mayparse the spreadsheet in different ways depending on what type of useraction is requested, as further described below.

In step 205 the webifier software may analyze the spreadsheet toidentify one or more user interface templates. A user interface templatemay include a data format for one or more data sources, e.g., a font,size, color, style, etc., and/or may include a selection oridentification of one or more data sources, each of which may includeone or more data records. A user interface template may also include thedata sources and records themselves.

Next, in step 207, the webifier software may generate a web data storeusing the data from the spreadsheet. The web data store may include alldata from the spreadsheet, or only a subset of the data from thespreadsheet based on one or more criteria or limitations set by thedesigner, either in the spreadsheet itself or during the generationprocess. Alternatively, the web data store may comprise the spreadsheetitself or may be comprised in the spreadsheet.

In step 209 the webifier may generate one or more web pages as part of adynamic interactive web application. Each web page may be based on oneor more user interface templates identified in step 205. Each userinterface template may define and/or identify a data format and/or oneor more data sources for inclusion on a web page. Each web page, uponrendering or generation for transmission to an end-user browser, may bepopulated with data from the web data store meeting the criteria setforth in the user interface template. Where the user interface templatecomprises the data sources and records themselves, the resultant webpage may appear as a simple web table based on the data in thespreadsheet.

One or more web pages may be generated as an interactive web page, forexample as a result of the designer specifying an interactive capabilityas part of the user interface template, or as a result of the designerrequesting interactive capabilities when instructing the webifiersoftware to generate the corresponding web page.

In step 211, when a web page is interactive, the web application mayreceive user input to edit one or more data records via the web page,e.g., using form fields, input boxes, or any other user input mechanic.In step 213 the web application updates the web data store based on theuser input, e.g., adding, editing, deleting, and/or otherwise amendingthe data previously stored in the web data store. In step 215, thewebifier software and/or the web application may be used to update datain the original blueprint spreadsheet used to generate the webapplication in the first place, or may output the data to a newspreadsheet. When replacing the data in the blueprint spreadsheet, dataformatting may be retained, and only the data is replaced/amended.

The above method is described with respect to a web softwareapplication. However, instead of web pages the webifier software mayadditionally and/or alternatively generate a standalone softwareapplication for direct use on a particular computer or computers,thereby alleviating the need for network access when using the softwareapplication. The above method may thereby be used to create customand/or complex software applications. A “complex” application refers toan application having multiple features such as data input, reports,multiple users, per-user security access settings, workflows, automaticnotification systems, saving of historic information, logging of changesby all users, and/or file attachments, among others. A “custom”application may refer to software built to fit a particular business'sneeds, no matter how unique the requirements. Results of such a customapplication are not off-the-shelf (out of the box) software designed todo one common thing, although custom applications can often do that too.Thus, the webifier software may not be tied to a single purpose. Rather,the webifier software is dynamic and flexible, and may be able to beused by anyone with average skill using sophisticated softwareapplications such as a productivity suite of software, and thereby actsas a replacement to hiring a custom software developer.

In an illustrative implementation, there are at least two types of usersor actors in the system. First is a designer, which is the person orpersons designing a software, web or mobile application using thewebifier software. A second is a visitor or end-user as the person(s)who visit the end result webpages, standalone application, or uses theresulting mobile application in ways largely intended by the designer.

FIG. 3A depicts an illustrative software architecture where thedestination system 350 comprises the webifier logic 353 and memory 351,and an a spreadsheet client application 354 (e.g., MS EXCEL) with awebifier Add-On 357 installed. The Add-On 357 may load its interfacefrom the destination system 350 using http requests.

As further illustrated by FIG. 3A, a designer may create or make recordsheet and template sheet changes to familiar worksheets using thespreadsheet application 354 and the data changes are observed 301 a bythe Add-On 357, e.g., using Excel's COM Interop library. When thedesigner has completed a group of changes, the Add-On 357 may send 302the updated partial, or alternatively full, spreadsheet definition tothe destination system's 350 webifier logic 353 using web-service APIcalls. The webifier logic 353 may process the new data and update 303data stored in memory 351 (e.g., a web data store). The designer maycreate or make changes to destination page configuration using theAdd-on 357, which may be sent 302 to the webifier logic controller 353as web-service API calls. Additionally, the designer may create or makechanges in a browser 355 accessing the destination system, which may besent 301 b to the Webifier logic controller as http requests orweb-service API calls.

Responsive to an http get request 304 from a visitor's browser 356 tothe webifier logic 353 to provide a destination page, the webifier logic353 may retrieve 305 the spreadsheet definition from memory 351. Thewebifier logic converts the spreadsheet definition into an htmldestination page by evaluating and referencing values and formattingfrom the template sheet and evaluating and referencing values from therecord sheet identified based on the template sheets. The destinationpage may be sent 306 to the visitor's browser 356. FIG. 3A furtherillustrates the visitor sees a page having text labels found only in thetemplate sheet and not in the record sheet, text labels originating fromRecordSheet!A1, values of “100” from evaluating RecordSheet!C2, and htmlinput controls defined by the template sheet with values from theRecordSheet, RecordSheet!A2 for the checkbox and RecordSheet!B2 for thetextbox. FIG. 3A illustrates the visitor checking the checkbox andclicking submit in the browser 356 resulting in the browser sending anhttp post request 307 to the webifier logic controller 353. The webifierlogic 353 may reload the current spreadsheet definition from memory 305.The webifier logic 353 processes the post request and updates the memory351 with an updated spreadsheet definition. If the designer's Add-On 357still has an active session, webifier logic 353 may send 308 the updatedpartial spreadsheet definition, or change events sufficient to updatethe spreadsheet definition presented, to the Add-On 357, then usingExcel's COM Interop library the Add-On 357 may present 309 an updatedversion to the designer in the spreadsheet application 354 such that thedesigner's worksheet would then display “true” in cell A2.

FIG. 3B depicts an alternative illustrative software architecture usingtight integration between spreadsheet and webifier logic, described inmore detail below in the section entitled Tight Integration.

Additional details regarding illustrative aspects of the webifier systemwill now be described in more detail below with additional reference toFIGS. 4-98 , which show illustrative screenshots of a spreadsheet-basedsoftware application development system according to one or moreillustrative aspects described herein. The depicted screenshots areillustrative in nature, and are not intended to limit the scope of anyaspect described herein. The illustrative screenshots are not meant tolimit a webifier to use with a particular spreadsheet application orwith any particular system architecture. Rather, the screenshotsillustrate various features and capabilities of the webifier system,regardless of whether used with local or cloud based spreadsheetapplications.

FIGS. 4-10 are screenshots of a spreadsheet application, with the Add-Oninstalled, having available formula functions specific to the Webifier.

FIG. 11 is a screenshot of the Add-On's page list showing a popupthumbnail preview of the destination page that visitors may see whenvisiting that page.

FIG. 12 is a screenshot of a spreadsheet application with the Add-Oninstalled where an additional menu has been added to the spreadsheetapplication toolbar, where the user is logged in, and showing the Add-Oninterface within a frame on the side of the spreadsheet application witha list of web-apps available.

FIG. 13 is a screenshot of a spreadsheet application with the Add-Oninstalled where an additional menu has been added to the spreadsheetapplication toolbar, where the user is not logged in, and showing thelogin page.

FIG. 14 is a screenshot of a spreadsheet application with the Add-Oninstalled where an additional menu option has been added to the rightclick menu of a cell.

FIG. 15 is a screenshot of a gamification user notification popup.

FIG. 16 is a screenshot of a list of web-apps, organized by source ofthe app.

FIG. 17 is a screenshot of an activated actions menu for one app on thelist of web-apps. The webifier has limited the available appmanipulations because the web-app permissions were limited by the owneddesigner, as in FIG. 21 .

FIG. 18 is a screenshot of an empty list of pages for the currentlyselected app “Test-Copy”.

FIG. 19 is a screenshot of the activated “App Information” dialog on thelist of web-apps, showing summary information about a specific web-app.

FIG. 20 is a diagram illustrating a source spreadsheet definitioncontaining a traditional spreadsheet table and that table beingreferenced in a report page as a record source, and illustrating theresulting destination page which was defined using the spreadsheetdefinition. The diagram further illustrates that for the specific loggedin visitor “Halee”, the webifier has filtered the record set down toonly row 2 where cell A2 matched the logged in username and the formula,as seen in the top-right of the screenshot, “=ISLOGGEDINWEBUSER(A2)”returned true when evaluated on the destination system. The diagram alsoillustrates that the function ISLOGGEDINWEBUSER returned alternatingplaceholder values during design-time but evaluated correctly when thelogged in visitor was known when rendering the destination page.

FIG. 21 is a screenshot of an app being shared with other users, and thedesigner specifying the permissions they would like the added designerto have for the web-app.

FIG. 22 is a screenshot of the template menu with an option tosingle-click copy a template into a new modifiable web-app.

FIG. 23 is a screenshot of a user who has clicked the upload optionafter creating a new spreadsheet in a spreadsheet application, and isnow presented with an upload dialog to name the new app and where thename is defaulted to the name of the spreadsheet file that was createdearlier.

FIG. 24 is a screenshot of the Shares tab for a destination page named“API_Page”, and the designer specifying whether that a login is requiredto access that page as well as a list of users allowed to access thatpage.

FIG. 25 is a screenshot of a dialog opened from the Shares tab to add auser, based on their email address, to the list of users allowed toaccess that page.

FIG. 26 is a screenshot of an API type of page being defined, whichcreates a web-service API page that can be access programmatically andwhich has inputs corresponding to a particular insert page specified bythe designer.

FIG. 27 is a screenshot of a calendar type of page being defined. Thespreadsheet shows the record sheets and the thumbnail illustrates thecomplex control that visitors would see. The range controls are set toappropriate columns on the record sheets.

FIG. 28 is a screenshot of additional options available to define acalendar type of page.

FIG. 29 is a screenshot of a container type of page being defined ineasy mode.

FIG. 30 is a screenshot of a container type of page being defined inadvanced mode.

FIG. 31 is a screenshot of a container type of page being defined ingraphic designer mode.

FIG. 32 is a screenshot of additional options available to define acontainer type of page.

FIG. 33 is a screenshot of a CSV Import type of page being defined. Thethumbnail demonstrates a complex set of controls that will be presentedto visitors of the page and the source is set to an entire worksheet byname.

FIG. 34 is a screenshot of additional options available to define a CSVImport type of page.

FIG. 35 is a screenshot of a Details Report type of page being defined,with the designer selecting a template sheet based on a NamedRange/Defined Name. The screenshot shows the various options fortemplate source referencing.

FIG. 36 is a screenshot of a Details Report type of page being defined,with the designer selecting a template sheet based on a custom range ofB9:C12 that has been selected from the spreadsheet tool's cells andwhere the designer has clicked the “use selected” button in the templatedefinition section.

FIG. 37 is a screenshot of additional options available to define aDetails Report type of page. The screenshot also illustrates alight-green overlay on the spreadsheet tool's cells, as well as alisting of functions that are available to the designer to use withinthe template definition. Function details are defined in FIGS. 4-10 .

FIG. 38 is a screenshot of an Edit-Cells type of page being defined.

FIG. 39 is a screenshot of additional options available to define anEdit-Cells type of page. The screenshot also illustrates the headerrange being defined by a custom range based on the currently selectedB1:C1 cells in the spreadsheet tool.

FIG. 40 is a screenshot of the various options to define the headerrange for an Edit-Cells type of page.

FIG. 41 is a screenshot of an Edit-Record type of page being defined,with the designer specifying that the orientation of the source recordsheet is row-based such that each row represents a different record.

FIG. 43 is a screenshot of an Insert type of page being defined, withthe thumbnail illustrating a preview of an automatically generated htmlform that may be seen by visitors of the destination page.

FIG. 44 is a screenshot of the various options for an Insert type ofpage. It further illustrates some of the data validators that thewebifier supports.

FIG. 45 is a screenshot of a Link type of page being defined, with athumbnail illustrating a preview of a hyperlink that will be generatedbut with the formula functions showing placeholder values rather thanactual values, and where the destination the visitor will be directed toupon clicking the link is specified as a specific calendar destinationpage.

FIG. 46 is a screenshot of a PDF type of page being defined, with athumbnail illustrating a preview of the PDF with a form embedded in thePDF that will be generated based on the designer selecting a previouslycreated insert destination page as the basis for the PDF.

FIG. 47 is a screenshot of a Report type of page being defined, wherethe report does not have a separately defined template sheet. Thethumbnail illustrates that the row-record sheet will result in adestination page that lists out all of the records with the sameformatting as the cells of the row record sheet.

FIG. 49 is a screenshot of a Tabs Container type of page being defined,where the designer has selected two previously created destination pagesto be contained within tabs. The thumbnail illustrates a destinationpage that will have two visual tabs at the top of the page, with eachtab having one of the previously created pages as the basis for thecontent.

FIG. 50 is a screenshot of a Text type of page being defined, where thedesigner can input rich text using a WYSIWYG editor.

FIG. 51 is a screenshot of the system presenting options for the type ofpage to be added after receiving a request from the designer to add apage.

FIG. 52 is a screenshot of a Report type of page being defined, wherebythe webifier has automatically detected that charts are available in thespreadsheet and the webifier displays a dropdown listing of charts thatcould be displayed on a report destination page.

FIG. 53 is a screenshot of the Add-On being notified by the destinationsystem that changes from visitors have been received and detected andwill either be downloaded automatically or the designer is able to clickdownload data to retrieve them at a desired time.

FIG. 54 is a screenshot of the page list where the designer has clickedthe actions menu for a page and the Add-On is presenting supportedmanipulation options for the destination page, such as duplicating ordeleting the page.

FIG. 55 is a screenshot of the Add-On displaying the web-app action menufrom within the page listing, with various manipulation options for theentire web-app such as duplicating the web-app.

FIG. 56 is example documentation for a destination system web-serviceAPI function call available to external systems or the Add-On,demonstrating a typical usage and request format for the web-service APIcalls.

FIG. 57 is a screenshot of a destination report page, illustrating theresult of a report page type being defined using a template sheet todefine the layout to have row records listed on the left, some links atthe top, and a clickable icon on the right to popup a chat.

FIG. 58 is a screenshot of the destination system retrieving chatrecords and prompting visitors to input new chat, after a chat objecthas been accessed by a visitor.

FIG. 59 is a screenshot with an example spreadsheet, wherein a chatobject is being created with the formula function and a GUID passed inas a parameter to indicate what group of chat records is associated withthat chat object. In this example, the visible placeholder text shown inthe cell during design-time is the GUID passed in.

FIG. 60 is a screenshot with an example spreadsheet, illustrating howseveral external supplementary data objects can be used within aspreadsheet: chat, file, and image objects. The screenshot illustrateshow there may be placeholder text, as in the case of the GUID for thefile or # None when no image is inserted, or other captions specified asparameters to the formula functions (e.g., FIG. 5 ), as in the case of“10 KB” for the file object showing a size. It also illustrates how twocells can refer to the same external data object, in this case E7 andF7.

FIG. 61 is a screenshot of a destination report page as could be createdfrom the spreadsheet in FIG. 60 . The page illustrates how theplaceholder text is replaced with an interactive chat object and thatthe cells E7 and F7 now allow the page to show multiple attributes of anexternal supplementary data object.

FIG. 62 is a screenshot of the destination report page in FIG. 61 havingthe ability to accept additional image files by way of an upload dialogfrom the browser. The screenshot also illustrates that interacting withthe image object on the destination page caused the controls to changefrom a simple text label to those appropriate for choosing a file andthat the system supports the designer specifying permissions for thevisitor to change the formula of an image object, allowing the visitorto change what file bin the upload would go to.

FIG. 63 is a screenshot of the destination report page in FIG. 61displaying the currently stored image for that image object, after avisitor has uploaded the image to the image object via the destinationpage.

FIG. 64 is a screenshot of the example spreadsheet in FIG. 60 where theparameter to the formula function is an arbitrary text string rather ana GUID.

FIG. 65 is a screenshot of a destination system admin page that allowsthe designer to specify programmatic or automatic clients that areallowed to connect to the destination system and what authenticationparameters are required for the client to do so.

FIG. 66 is a screenshot of a destination system page which has anavigation menu of other pages dropping down from the web-app“Timesheet”.

FIG. 67 is a screenshot of the destination system admin pages allowing aweb-app to be exported as a single, self-contained, file containing thespreadsheet definition, both record sheets and template sheets, as wellas the sharing and notification settings.

FIG. 68 is a screenshot of the destination system admin pages uploaddialog which allows uploading of a spreadsheet definition, with the sameoptions of importing information exported from FIG. 67 .

FIG. 69 is a screenshot of an activated actions menu for one app on thelist of web-apps. Unlike FIG. 17 , the webifier has provided access toadditional manipulations such as “add page” because the designer has theappropriate permissions on the web-app.

FIG. 70-73 is a screenshot of a destination system admin page allowing adesigner to define an Insert, Link, Report, and Text type of pages, muchlike FIGS. 43, 45, 47, and 50 respectively, but without the need for anAdd-On or third-party spreadsheet tool.

FIG. 74 is a screenshot of a traditional spreadsheet table, illustratingthe table can have controls to filter the spreadsheet records based onthe values in column C, and illustrating additional filtering ofspreadsheet records using a formula such as a date formula on column H.

FIG. 75 is a screenshot of a destination system admin page supporting apage type of webpage to an arbitrary external URL and allowing a varietyof potential sources, not just necessarily URLs.

FIG. 76 is a screenshot of a destination system admin page illustratingthe webifier's ability to have deeply nested containers.

FIG. 77 is a screenshot of some additional options the destinationsystem supports for an edit-record type of page, with editability fromthe destination system admin pages.

FIG. 78 is a screenshot of some additional options, similar to thoseseen in FIG. 44 , the destination system supports for an insert type ofpage, with the ability to edit the options from the destination systemadmin pages rather than the Add-On.

FIG. 79 is a screenshot of illustrating the destination system providingoptions to restrict user input, otherwise known as data validation, andwhere the data validation rules can be specific to the type of datavalues being stored.

FIG. 80 is a screenshot of illustrating the destination system providingoptions to restrict user input with part of the data validation rulereferencing a range of cells in the spreadsheet definition. In thisexample, the system supports an entire sheet or a custom range of cellswithin a sheet.

FIG. 81 is a screenshot of the destination system's support to modifythe editable range within various types of pages, such that everythingoutside of the range is not editable. It illustrates support for aliasessuch as “Everything”, using Named Ranges, as well as custom rangesspecified by the designer.

FIG. 82 is an example of HTML code that the destination system canautomatically generate in order to have an embedded destination pagewithin any external site page.

FIG. 83 is a screenshot of the destination system's notificationsettings page, illustrating various options for notification settings,support for web-service API calls for notifications to externalautomated systems, and multiple types of notifications.

FIG. 84 is a screenshot of the destination system's configurationoptions for a particular notification. It illustrates its webhookability by way of a URL specified by the designer, as well as emailability.

FIG. 85 is a screenshot of the destination system's configurationoptions for a particular notification's email template.

FIG. 86 is a screenshot of a destination CSV Import page, illustratingthat the webifier accepts CSV files during the import, is able to makeuse of metadata about the record sheet it is linked to by analyzing thespreadsheets, and is able to report on the status of the request toinsert into the record sheet.

FIG. 87 is a screenshot of a destination CSV Import page as in FIG. 86 ,but illustrating that the system is able to enforce, and report on thefailure of, data validation rules when data arrives via CSV Importforms.

FIG. 88 is a screenshot of a destination Edit-Cells page, illustratingthe result of an Edit-Cells page type being defined from the Add-Oninterface illustrated in FIG. 38 , and the destination page's controlschanging for any cell that switches to “edit mode” as a result of userinteraction.

FIG. 89 is a screenshot of a destination Edit-Record page, illustratingthe result of an Edit-Record page type being defined, the dynamicnotification messages to the user as a result of deleting a row, andcontrols amending of the template sheet definition when the destinationsystem determines the “Edit” and “Delete” permissions are enabled andthe page definition has those options enabled.

FIG. 90 is a screenshot of a destination Edit-Record page when the “EditRow” button in FIG. 89 has been clicked by a visitor, illustrating anautomatically generated input form used when no template sheet has beendefined and illustrating the input form can have controls such asdropdowns where the options are defined by the spreadsheet definition.

FIG. 91 is a screenshot of a destination Insert page before the visitorhas filled out any fields in the form, illustrating notifications to thevisitor confirming the submit has modified the record sheet andillustrating that the destination page may present fields with defaultvalues as well as uneditable fields, based on data validation rules.

FIG. 92 is a screenshot of a complex interactive control being displayedto a visitor of the destination Insert page, as in FIG. 91 , when thevisitor inputs data for a field where the spreadsheet definition'sassociated cell datatype is set to a date.

FIG. 93 is a screenshot of a destination Insert page after a visitor hasfailed input data validation rules, illustrating a modification to theinterface to inform the visitor of the failure.

FIG. 94 is a screenshot of a destination system admin page allowing adesigner with administrative permissions on the server to control accesspermissions pertaining to administrative features of the destinationsystem, for a particular role, illustrating further the ability forroles to have sub-roles with cascading permissions.

FIG. 95 is a screenshot of a destination system admin page, illustratingvarious granular administrative permissions of the destination system.

FIG. 96 is a screenshot of a destination system admin page, illustratingthat complex password policies with numerous options are possible forvisitors logging into, or creating accounts on, the destination system.

FIG. 97 is a diagram illustrating a source spreadsheet definition,designed in a spreadsheet and with numerous formatting options beingspecified by a designer, to define the formatting of content on adestination page generated for a visitor.

FIG. 98 is a screenshot of a complex destination page involving a tabcontainer with three page tabs and with the first page tab having anested container page with multiple nested pages including anautomatically generated input form from an input page, a report page,and a report page whose source is a chart.

Spreadsheets and Records

For illustrative reference only, two usage styles of spreadsheets arereferenced herein. Other styles may alternatively be used. The first aresheet-records, where each record comprises an entire sheet or an entirefile compromising many sheets. For example, many companies save a newsales quote spreadsheet file for every sales quote they create. Thatfile may have several sheets, such as one sheet for backend calculationsand one sheet intending to have a printable quote, and the printablequote sheet would typically have many rows and columns that containtext, numbers, and formulas that result to text or numbers, allrepresenting that single quote. They may also contain sufficientformatting to allow a fairly readable print out.

The second is a row-record and row record sheet, where many records arespecified together, typically within a single sheet (e.g., FIG. 53 ,col. A-D). Spreadsheet files can have zero, one, and/or multiplerow-record sheets. Row-record sheets may be confined to only part of asheet (e.g., FIG. 60 , col. A-B), which may have additional row-recordsheets on it or unrelated data (e.g., FIG. 60 , col. E), but forsimplicity we refer to it still as a row-record sheet throughout. Forexample, many companies will have a client listing spreadsheet similarto the following. A sheet may have the top row 1 with some column namessuch as “Client” and “Industry” and “Client ID”. Each row below may havedata related to a single client. For example, row 2 may have “PleasantSolutions” in column A, “Software Development Services” in column B, and“1” in column C. Row 3 may have “NewCo” in column A, “Consulting” incolumn B, and “2” in column C. Despite the name, row-record alsorepresents a list with the purpose of rows and columns flipped so therecords are listed left to right, as if a column-record.

During steps 201-203, above, either or both techniques may be used,thereby allowing the webifier software to be used to create complex,multi-user, completely custom destination software with no preordainedor pre-implied purpose. Standalone, web or mobile applications (web andmobile may be collectively referred to as the “web-app” for convenience)may be created with no programming or database experience required. Someaspects described herein may be intended to replace the need to hire acustom software development company even for complex scenarios involvingdata, custom user interfaces, different viewing device capabilities,concurrent usage, data and user workflow, automatic notifications,scheduled events, business logic, and more.

Template Sheets

Steps 201 and 205 are now described in more detail with respect to userinterface templates, with reference to an illustrative implementation.Regardless of whether done in a traditional spreadsheet application, acloud and web based spreadsheet, or a simplified spreadsheet interfaceembedded within a web application, a spreadsheet tool may be used tomake a spreadsheet that represents a desired user interface for thevisitor or report layout. For example, the template could have one sheetwhich has many rows and columns that contain values and formulas thatwould be pertinent to a single quote: a large font text title of clientnear the top, followed by a row that has the first value as “InvoiceNumber” and a cell to the right of that which will be intended todisplay an actual invoice number. A few rows below may have a cellspanning multiple rows and columns and intended to display comments initalics. Near the bottom of the sheet, a cell that is labelled“Subtotal” and to the right of it a cell that has cell formatting tospecify a currency with “S” symbols and intended to have a numberrepresenting the total for that particular invoice (with that cellhaving a location of C15 on the grid). The next rows may have cellsrelated to taxes and totals after taxes, but rather than intending tohave values located there later, the tax and total cells would havespreadsheet formulas that reference the subtotal cell locations, such as“=C15*10%”, where it is intended that changes to C15 would affect thetotals based on those formulas.

Template Sheets may be nested, such as in a many to many relationshipbetween parent template and nested template, and/or to several levels ofdepth (FIG. 76 ). According to one aspect the webifier software maydefine a spreadsheet formula function such as “USETEMPLATE( )” thataccepts a cell range reference or a template identifier for whattemplate sheet should be used. The cell that the formula is used in mayimplicitly provide some information such as where to insert the nestedtemplate sheet based on the cell's location, or the width and heightallocated to the nested template based on the cell's size. If the sourcerecord(s) for populating the template are not the same as the parenttemplate, parameters could be passed in to the USETEMPLATE function thatwould allow the template to know what source data, in much the same wayas a non-nested template sheet does for some page types (as furtherdescribed below). This allows for scenarios such as an invoice templatecontaining a list of “invoice items” within it that needs to bepopulated from records on different record sheets. Typically, such anested template sheet would make use of the traditional spreadsheet“merge cells” feature to allow it sufficient width and height to displaywithout affecting the parent template's row or column alignments, aswell as the traditional table feature to provide record filtering(described below) to only those invoice items belonging to a particularinvoice.

The webifier software may allow for Template Sheet cells to haveformulas that reference other cells within the Template Sheet, cellswithin other Template Sheets, record sheet data, or a mix of all of theabove within the same cell. The techniques described also allow one ormore templates to be used for input functionality and one or moredifferent templates to be used for output functionality to concurrentlybe made available to visitors of the destination system, even if theunderlying source references are identical or overlap in part. Theformulas are typically declarative in nature, but any formulas orequations supported by any spreadsheet tools, and/or new formats orsyntaxes, may be used.

Sheet Templates Having Record Formulas (Template Indicators) orReferencing Sheet Data

While designing the template sheet in a spreadsheet tool, the cellsintending to represent a particular record or aggregation values derivedfrom many records may evaluate to be blank and/or have placeholdervalues that have no effect on the system other than to indicateformatting to the designer. An external list or database may contain across reference of the cell locations, such as C15, and their intendedpurpose, such as displaying a subtotal of an invoice. Alternatively, ifthe record sheet cells are referenceable from the template sheet,formulas or placeholder formulas can be inserted in those cells thatrefer to the records. For example, the client title cell on the templatemay have a formula such as “=ClientList!A1” which would potentially beevaluated by the spreadsheet tool into the text “Client” during designtime as a placeholder, or perhaps the formula would be “=ClientList!A2”which would potentially be resolved by the spreadsheet tool as “PleasantSolutions” during design time as a placeholder. Additionally, the refcould be to “=ClientList!A:A” or “=ClientList!A1:A1000” resulting inblanks, errors, or unintended values. In each of the above case, thetext that results during design time is merely a design time placeholderand is not as important as the formula itself which has the usefulinformation of which column on the ClientList is to be used in fillingout the template, to assist the webifier during actual evaluation at alater point, such as for visitors. For convenience, this concept can begenerally referred to as Template Indicators.

The Template Indicator formula could be typed by a designer or derivedfrom dragging and dropping from a list of available or relevant columnsof data. The formulas can be typical to the spreadsheet tool's cellreferences (“=ClientList!A1” or “=ClientList!Client” in the case of anamed table), typical function call syntax that triggers specializedactions for this purposes (“=GetRowRecordData(“Client”)”), or they canbe a specialized separate format, such as “[[Client]]”. The formulas maybe stored in a cell as is typical of spreadsheets, or they could bestored in a special external list of formulas along with informationabout what cells they are to be applied on.

Spreadsheet Definition Goes into Destination System

Step 207 (FIG. 2 ) may further include, once the spreadsheet isconfigured as desired with the applicable data, the designer initiatingthe process to build the destination system using the webifier software,described here with respect to one or more illustrative embodiments. Theuser may login to the destination system (FIG. 13 ) and visit an adminwebpage that accepts spreadsheets. For example, the webifier softwaremay have an input form that accepts the uploading of a xlsx spreadsheetfile (FIG. 68 ), e.g., data 129 (FIG. 1 ). Alternatively, the webifiermay have integration to fetch the spreadsheet definition via aweb-service API from a cloud and web based spreadsheet tool, either agroup of sheets at a time, if the API allows it, or even cell by cell,if the API requires it. For brevity, all these methods are referred toherein as “uploading”, or uploading of spreadsheet definitions or datafiles into the webifier data store, e.g., database 131 (FIG. 1 ).Notably, separate steps are not required for uploading records anduploading interface templates, they can occur with one step from thedesigner from one spreadsheet definition, or they may occur at separatetimes.

The webifier may store the spreadsheet definition temporarily, replacingit with an alternate and more efficient format, or an intermediaryformat that is or isn't considered a spreadsheet anymore. One examplethat achieves a balance of efficiency and simplicity of implementationis to convert the sheets into database entries whereby each cell withinthe sheet is one database record in a database table having 4 fieldsrepresenting the location of the cell and the content: sheet, column,row, content. The content may match the spreadsheet definition'soriginal schema, but cells may be looked-up efficiently in the database.The system may also store it permanently in the format received wherebyvisitor inputs on the destination system's pages are persisted bymodifying the spreadsheet definition directly, as described herein.

Creating Web Pages

As discussed above with respect to step 209 (FIG. 2 ), the resultantsoftware may include a web application comprising one or more web pages,discussed here with respect to an illustrative implementation. Thedesigner may select a “Add Page” feature in the webifier software'sadmin interface (FIGS. 18, 69, and 55 ) and select from a variety ofpages types (FIG. 51 ) and configuration options (FIG. 52 ). It ispossible that cell data or metadata within the spreadsheet definition,contains indicators or instructions to create new pages, what types ofpages were intended by the designer, and their various configurationoptions; but absent this information the designer may be prompted. Awide variety of page types are possible to create on the destinationserver. Typically, a menu of all generated destination pages aredisplayed as a menu on all destination pages to allow for convenientnavigation throughout the web app (FIG. 66 , “Timesheet” web app menulists all three destination pages for that particular example), and thedestination pages may be grouped by “apps” which are typically groupedbased on what spreadsheet definitions or files they came from and/orgrouped by the designer who created them (the logged in designer, orfrom other designers who have shared spreadsheet definitions with thelogged in designer, or other groupings) (FIG. 16 ). The ordering ofdestination pages within the destination system's menu can be modifiedby the designer dragging and dropping the pages to change their orderingfrom within the Add-On.

Add Page (Report Page)+Viewable Source Range

One illustrative type of web page that the webifier software may createis a “report” page type. A title for the report may be specified by theuser, or generated from spreadsheet data or titles (FIG. 52 ). A sourcemay also be specified. The source can be the sheet name within thespreadsheet definition (similar to the source control for a CSV_Importpage type as shown in FIG. 33 ), a typical spreadsheet cell rangereference such as “=B9:C12” (FIG. 36 ), name of a chart defined withinthe spreadsheet (FIG. 52 ), or a spreadsheet “named range” (sometimesknown as “defined name”) which is a cell range that is referable by aname such as “TotalColumn” or “PrintableArea” or “EmployeeList:Employee” (FIG. 36 ). In general, ranges do not have to be acontinuous block, they may comprise several blocks and cells. Forexample, “A1:A8,A10,A30:B30”. Many pages may reference the same sourcecells, the source cells may partially overlap with another page'ssource, or a page may have a series of sources to be combined. This maybe sufficient configuration for the destination system to show an HTMLweb report or mobile screen to visitors based on the report the designerdesigned in a spreadsheet tool. For example, the ClientList sheet couldbe specified with all of the row-records in a list now becomingaccessible to visitors. Numerous optional configurations may bespecified such as “Show Page Title” (FIG. 28 ). Permission rules mayalso be specified on the app or page to control whether login isrequired to view the page (FIG. 24 ) what logged in users or groups ofusers or roles are allowed to view the page and from what devices,networks, or during what times of day. FIG. 25 illustrates a simplifiedexample, showing what logged in users are allowed to view on the page.The end result is a web page displaying a report that looks similar tothe original template spreadsheet that supplies the data, including thelayout and formatting of the data (FIG. 97 ), without requiring the userto have knowledge of web design.

A destination page's Source data could, rather than a cell range, belinked to a specific element within the spreadsheet definition, such asa chart positioned to be floating overtop of the cells.

Some page types may have options that automatically add severalpreconfigured controls to the destination page. For example, an “allowsearch” (FIG. 48 ) or “allow PDF export” (not shown) option is availableon some page types such as the calendar page type, which could result inthe destination pages not only having the intended calendar but alsomultiple controls such as a search textbox and search submit button todraw the user's attention to particular data by methods such asscrolling and focusing the search result. Processing of search resultsmay be performed client-side or server-side.

Add Insert Page+Default Form Generation

Another type of page that webifier can create is an “insert” page type,e.g., as may be used during step 211 (FIG. 2 ), above (FIG. 43 ),according to an illustrative embodiment. Similarly, a source ofClientList may be specified and an indicator if the designer intends fora row or a column to be insertable by visitors. A range of cellsrepresenting the header row(s) may be automatically identified ordetected and presented to the user for override (FIG. 39 ). Detectioncan, for example, be based on location of cells (FIG. 40 demonstratingdetection that the first item is a header), differences in formattingsuch as font boldness or underlining compared to listed rows below, orsimply taking the first row of the sheet. The destination system canprovide a list of other pages as options to redirect the visitorautomatically after an insert is complete by a visitor (FIG. 44 ). Thedestination system may then show an automatically generated input formto visitors, having labels based on the columns in the header row besidetheir respective input controls, and allow visitors to insert data (FIG.91 ). The cell formatting from the spreadsheet's ClientList may affectthe html formatting of the cell labels and input controls on theautomatically generated input form. The labels for each input field maybe determined by the “Header Source” and are typically either the firstrow of the source range, a Defined Name or a range selected by the user.

In addition to specifying restrictions in the spreadsheet definitions,the types of inputs on the form can be manually specified or restrictedfurther by the designer with the “restriction user input” options on theMore Settings tab for each field from the Add-On or destination systemadmin pages (FIG. 78 ): “User of Page” and “Current Date” restrictions(FIG. 44 ), for example, may present uneditable fields with the name ofthe logged in user or the current date already filled out (FIG. 91 );Some columns may have formulas that are copied down from previousrecords and are also uneditable; “Whole Number” and “Decimal” withpresent numerical inputs that only allow the selected type of number;“List” may present a dropdown input containing the values from thespecified range; “Date” presents a calendar for selecting a date (FIG.92 ); “Time” presents a 24-hour time picker; “None” and “Text Length”may present a text field.

Add Insert Page+Custom UI (Template Sources)

If the insert page has more complexity or custom requirements, thedesigner could also specify a “Template Source” within a spreadsheet(FIG. 35 ) in addition to the first ClientList source within aspreadsheet, according to an illustrative embodiment. It would stillperform the insert into the list of clients, but the input form userinterface may be defined by the Template Source. Wherever a TemplateIndicator is found on that Template Source, the display of a cell may besubstituted for an automatically generated input control, withformatting of the input control taken from the Template Indicator cells'formatting.

Add Details Page+List-to-Details Navigation

Another page type is a “details” page based on a specified record sourceand template source, according to an illustrative embodiment. Thedestination system may place controls above the result of rendering thetemplated report, that allows a visitor to select which record thetemplate should be applied against. As an alternative, the details pagemay be used in combination with a report page. Both the report page anddetails page would have as a source a ClientList spreadsheet. TheClientList spreadsheet may have an added column called “Go To Details”and each row would have a formula such as “=NAVIGATETO(‘DetailsPage’,A3:Z3, Blue, LinkStyle)” that would indicate to the destination systemthat during the display of the main report page that lists all of theclients, a hyperlink style navigation control should be visible on eachrow that would take the visitor to the DetailsPage populated by row 3 orthe respective row that was clicked on. As another alternative, aconfiguration option during report page creation may prompt the designerto specify the navigation links to be generated rather than having themspecified right within the ClientList spreadsheet. The cell formattingof the evaluated record values on the details page may be a mix of theTemplate Indicators cell formatting combined with the formatting of anygiven row of cells populating the Template Indicators cells with recorddata, one overriding the other depending on destination system defaultbehavior and designer selected preferences for which formatting takespriority if both cells have formatting that conflict versus formattingthat is combinable (such as a color change on the record combined with alarger font size on the template). The destination system may alsoanalyze the records to ensure the most common formats do not overridethe template formats, but some rare and therefore deliberate formattingchanges may be permitted to override the template formats.

Add Edit Cells and Edit Record Pages

For a visitor to edit cells from within a destination page on thedestination system, the designer can create an Edit Cells page (FIG. 38), or an Edit-Record (FIG. 41 ) page, according to an illustrativeembodiment. From the page creation webpage, they may be createdsimilarly, by entering a title and selecting page type “Edit-Cells” or“Edit-Record”. An Edit-Cells page allows visitors to edit individualcells, but displays the page much like the report page, until thevisitor begins interacting with visible elements (FIG. 88 ). AnEdit-Record page may allow visitors to browse records (FIG. 89 ), editand/or delete rows or columns and may be analogous to the insert pagewith default form generation (FIG. 90 ). The page source may be therange of cell values to be displayed on the page, and by default thesecond range that specifies what cells can be edited (FIG. 42 ) matchesthe page source such that all cells are editable. The ranges may be anentire worksheet, a defined name, and/or a custom range. The destinationsystem consults the source range to display every cell with data andcells between those with data. Both edit pages may also have anadditional row and/or column of empty space, to allow users to expandthe record set by inserting. A defined name or custom range will onlyinclude the cells referenced by that range. The destination system mayimplement the custom range option by creating a defined name after arange is specified by the designer. The Edit-Record page type has anadditional selection of Row or Column (FIG. 41 ), which may determinethe edit buttons available on the page.

There are additional settings for both types of edit pages in the “More”section (FIGS. 39 and 42 ). The designer can specify a “Header Range”,using either the first row/column, or using a defined name or customrange. If a header range is selected, the designer can specify whetherthose headers are editable by visitors or not. The headers will appearas the first column of the page (FIG. 90 ) or top row in the case of acolumn Edit-Record page. The designer can also select an editable range,which must be contained inside the main page source. This editable rangemay be all the cells that can be edited by a user. There are alsooptions to show the page title, to allow searching the page, to displaygrid lines between cells, and to display row and column numbers/letters.

For Edit-Record type pages, there may be additional options to allowdeletions and edits (FIG. 42 ). Both are allowed by default. This maycause additional controls to appear on the destination page beside eachrecord (FIG. 89 ). A row/column may only be deleted from the page if“allow delete” is selected and all the cells in the row/column are inthe editable range. A row/column may only be edited from the page if“allow edit” is selected and at least one of the cells in the row/columnis in the editable range. In this case, only cells actually in theeditable range may be edited, according to some aspects.

When viewing an edit-cells type destination system page, the user canclick on any editable cell (editable cell range is defined whencreating/editing a page) to edit, according to an illustrativeembodiment. The contents of the table cell may be temporarily hidden andreplaced with input elements that depend on the cell number format, withthe cells' current contents as the default value (FIG. 88 ). Save andclose buttons are made visible as well. Text cells will display a textfield, number formats such as decimal or currency will display a numberpicker with the option of typing text, dates display a date picker, andtimes display a time picker. If a traditional spreadsheet datavalidation is set for the cell, this may also affect the input elementspresented, with a list validation presenting a dropdown, and numbersshowing a number picker. Destination system validations applied to pagesalso have the option of date, time, or map/GPS. Date and Time willdisplay date and time pickers respectively. Map/GPS will allow the userto enter GPS coordinates, or click on a map to generate them. Changingthese values and saving will change the value/formula of a cell in aspreadsheet definition in the same way it does in a spreadsheet tool. Ifthe cell contains a file reference using the WEBIFIERINSERTFILE formulafunction, the user will be given the option to upload a new file orimage (FIG. 62 ). Upon selecting save, the new data is sent to theserver, and a string value is returned to replace the contents of theedited cell. The save and close buttons may be hidden, and the celldisplays its value as usual. If a file was uploaded, the page isrefreshed. After clicking the save button the following may be sent tothe server: the page id, new cell value, row and column of the cell,cell type describing the type of data, and a Boolean indicating whetheror not the Destination system page is embedded in another webpage. If afile is uploaded, the file key, file id, and file data are sent as well.After the server processes the edit request, a JSON object is sent backto the client, specifying the new text to be displayed in the cell.

Add Calendar Pages

Calendar Pages may be created in the Add-On (FIG. 27 ), but they canalso be created through the website, according to an illustrativeembodiment. To create a Calendar Page, three pieces of data may be used:the Event Date (required, date formatted cells), the Event Time(optional, time formatted cells), and the Event Title (required). Theuser selects the Add Page button and then selects Calendar as a pagetype. Two options are available for how to input the cell range for eachof the parameters: Defined Name and Custom Range. The defined nameallows for the user to choose from a list of Defined Name optionsextracted from the attached Workbook. Custom Range allows for the userto specify a range either by pressing a “Use current selection” buttonor manually entering in the selector. After these parameters have beenspecified the page can be saved. The Date of the events may be the onlyrequired field, events without a title may default to “Event” and eventswithout a time may default to “All Day”. After uploading changes to theserver, the calendar page view displays a Calendar widget that includesthe specified Events. The three specified parameter sources areextracted and used to construct event objects consisting of Title, Date,and Time properties. These objects are then displayed on a calendarwidget, typically as a Title list within their appropriate date. Thethumbnail on the design page reflects and matches the rendered calendarwidget.

Add Nested Container Pages

Container pages are pages that can contain one or more instances ofanother page. They are created by selecting ‘Container’ from the Typedropdown during page creation. There may be at least three differentmodes that can be used to create a container page: Easy, Advanced, andGraphic Designer, that can be selected via buttons in the UI (FIG. 29 ).

Easy mode may render the subpages in a grid layout. Two pieces of datamay be required: the number of columns and the subpages that will beincluded in the container (FIG. 29 ). The number of rows in the finallayout will depend on how many pages are selected for the container.

Each subpage is selected via a dropdown menu during Easy mode creation.The dropdowns are laid out in a grid that reflects where each subpagewill appear on the rendered page. As pages are added, a new blank row ofdropdowns may be appended so more additional pages can be added. Theremay also be an option to create a new page and add it to the container,which may be saved when the container itself is saved. Likewise, if thenumber of columns is changed, dropdowns may be added or removed toreflect the new column count. The number of columns in a containercreated in Easy mode might be limited to some number, e.g., three.

Advanced Mode may use a WISYWYG—“What you see is what you get”—rich texteditor, allowing for more control over display of the container page(FIG. 30 ). The editor allows for advanced formatting like font size andcolor, bold text, bulleted lists, etc. The user can include whatevertextual data they want in the container. When saved, the textual data issaved as an HTML template.

Including subpages within a container created via Advanced mode may bedone by typing in the page name surrounded by the text “{{” and “}}”,according to an illustrative embodiment. For example, typing the phrase“{{DataPage}}” would include the page named “DataPage” in the container.When the container page is rendered, the template is searched forphrases in between the “{{” and “}}” markers. If the phrase matches avalid page name in the system, the phrase is replaced with an HTMLrendering of the matching page. The advantage of Advanced mode is thatseveral pages can be laid out with text intertwined, without having tocreate several Text type pages. It also allows greater control over thefinal appearance of the container page.

Graphic Designer mode is similar to Advanced mode, but a full HTML texteditor and preview function may be included (FIG. 31 ). The editor inGraphic Designer can switch between “Edit HTML”, “Preview”, and “Editor”views by using tabs located at the top of the editor.

The “Editor” tab contains the same editor as the Advanced mode editor.The HTML editor is located under the “Edit HTML” tab. Using the HTMLeditor, the user can input arbitrary markup allowing for even morecontrol over the final appearance of the container page. The “Preview”tab function takes the current markup and renders it, so the user canquickly see the appearance of the rendered template without needing tosave and view the page normally.

Advanced and Graphic Designer both feature a list of current pages onthe right hand side. When a page is clicked from this list, the page maybe automatically inserted into the template at the current cursorposition.

Advanced and Graphic Designer modes may also have a button to “ImportFrom Easy Mode”. Data may be required to be input using Easy mode firstto use this function. When pressed, the Advanced and Graphic Designereditor will become prefilled with a template that matches the originalappearance when the container was in Easy mode.

For all container modes, one or more rules may limit creation. One isthat a container page cannot contain the same Insert type page more thanonce. A second is that the container cannot contain itself or anothercontainer page that would cause an infinite loop (Example of a containerloop: Page ‘A’ includes Page but Page ‘B’ also contains ‘A’). Theserules are checked at the time of save and if violated, the container'screation may be prevented.

The webifier allows for both a record list and a user interface forvisitor actions such as insert, to be largely defined by a non-technicaldesigner within a spreadsheet tool, according to an illustrativeembodiment. All these report types may have as sources or TemplateSources spreadsheets that have formulas that represent aggregate data ofthe records, charts representing aggregate data, or essentially anythingthat is visible on a spreadsheet (FIG. 98 ). For example, the insertpage could have reference information as to the previously insertedrecord, or a graph of all records thus far to aid the visitor ininputting the next record. The nature of the relationships between dataand interface is left very broadly definable by the designer. The amountof flexibility the combination of using spreadsheets for source data andspreadsheets again for user interface layout and design is unexpectedlypowerful, giving new capabilities to millions of users who previouslyhave no software development experience or training.

A container page type may also be a tabs container type (FIG. 49 ).Rather than positioning multiple subpages on the same page, in multiplecolumns for example, each subpage would be displayed as a separate tabwhen the destination page is loaded to the visitor (FIG. 98 ).

Add CSV Import Pages

CSV Import pages (FIG. 86 ) allow a visitor to insert multiple rows intoa spreadsheet at once from a CSV file, according to an illustrativeembodiment. A designer can select a worksheet, defined name, or customrange as a source for a CSV import page (FIG. 33 ). This sourcedesignates where on the page the new data will be entered. It may or maynot restrict the number of columns allowed in imported CSV files. Forexample, a defined name source covering a range of $A$1:$C$1 would onlyallow CSV files with 3 columns, and the data would be inserted in thehighest available row spanning columns A, B, and C. Alternatively it mayignore the extra columns.

When using the page, the visitor may be told the expected number ofcolumns to be inserted. They may also have the option to exclude thefirst row of the CSV file. The visitor then selects a CSV file using astandard file upload control, and submits the page. The page may limitthe upload control to only accept .csv extensions. If the page containsno data, or improperly formatted data, an error is returned (FIG. 87 ).

Each row may be inserted one at a time in the columns designated by thesource, in the same way as an Insert Record page. Data validations, asdescribed below, still apply, so if any value does not meet restrictionsplaced on a cell, the import will be rejected, limited, or otherwisemodified and the visitor alerted. If the insert is successful, thevisitor may receive a success message displaying the number of rowsinserted.

Add Embedded-Spreadsheet Pages

Another page type that may be specified with a title and source range isan Embedded-Spreadsheet page, according to an illustrative embodiment.This page type displays an embedded spreadsheet interface to thevisitor, and allows the visitor to edit the values and formulas of adesigner specified portion of a spreadsheet in the same way the designerdoes. The implementation of the spreadsheet control need not becomprehensive nor does it require the visitor to have any ability toreference data outside of the spreadsheet. The implementation can makeuse of one of many commercially available spreadsheet web controls, thataccept data in a spreadsheet definition format and, upon the visitorsaving, produce a result in spreadsheet definition format where thecells formulas or cell values may be readily copied one by one to andfrom a temporary sheet provided to the spreadsheet control.

Additional Page Types

The webifier can support a multitude of other page types in similarfashion, according to an illustrative embodiment. For example, similarto the “report” page type described above, but the destination systemmay use a commercially available converter or print to PDF library toperform an additional step of converting or printing the report page'shtml into a PDF document which gets downloaded and opened by a browseror mobile application when a visitor accesses that PDF Page's URL.

Another example page type is the embedding of an external webpage into aframe on the destination page, where the URL of the frame is specifiedin the page configuration when creating the page, or is obtained bydereferencing a specified cell in the spreadsheet definition whichallows it to be provided by a static value or by a formula. This may beparticularly useful in scenarios where the spreadsheet record datashould define the webpage that a visitor is directed towards.

Extracting Spreadsheet Definition

Once the spreadsheet is defined, the webifier may generate thedestination system pages based on the spreadsheet definitions, accordingto an illustrative embodiment. In the example where the spreadsheetdefinition is persistently stored on the destination system, the processbegins with extracting and making available the definition of the cellsthat fall within the applicable source ranges (step 207, FIG. 2 ). Ifthe spreadsheet definition is starting out in xlsx file format, the filemay be unzipped to obtain the inner content which is in XML format. Avariety of XML parsing options, from rudimentary string parsing tosophisticated parsing typically done by calling functions in an XMLparsing library, are used to provide convenient access to iteratethrough all of the individual data items, including cells, and theirattributes as well as to load them into an alternate or intermediaryformat such as to in-memory object-oriented classes and instances.Alternatively, a commercially available spreadsheet file format parserthat is compatible with xlsx, MS-XLSB, SpreadsheetML, ODS formats, andsimilar schemas may be used to expose the data of the spreadsheet inobject-oriented classes conveniently specialized to the attributes andformat typically found in spreadsheet data.

In the example where the spreadsheet definition was not persistentlystored, and instead was persisted in an intermediary, or database,format, some of the above steps still apply but they may be performedfor all sheets on the system at an earlier stage, shortly after thedesigner provides the spreadsheet definition, rather than performedon-demand as requests for destination system pages are received by thesystem. Intermediary formats may include partially following these stepsat the earlier stage and partially on a per-request basis. For example,the early stage may accept an xlsx file, unzip it, and convert thenecessary files into database records representing an entire sheet, yetnot parse it further. In that case, the steps during each page requestto the destination system are fewer.

Conversion of Formatting and Attributes

During steps 207 and/or 209 (FIG. 2 ), the data may be converted to anintermediary format, which may make relevant data attributes moreconveniently accessible in classes that more closely resemble CSS orHTML classes rather than spreadsheet classes, according to anillustrative embodiment. For example, the property names on the classesmay match the property names of CSS, or there may be methods on theclass such as “ObtainCSSDefinition( )”. The convenience of anintermediary format is not required however, as alternatively thewebifier may store data according to the destination page's outputformat of CSS and HTML, or may store data in the original spreadsheetformat and later stream straight to the output form with no intermediarystorage. For example, to process the width of a column, one could readthe value of the “width” attribute of the XML snippet “<col min=“1”max=“2” width=“11.8”>”, convert to units supported by CSS, and store theresult in a column class's “csswidth” property or stream it out as“width: 100 px;” as part of a CSS output streaming function.

Conditional formatting entries found within the spreadsheet definition,which are common to traditional spreadsheets, may cause the destinationsystem to perform formula evaluation on the formula that the designerspecified is associated with the formatting definition of a cell. If theformula evaluates to true when the destination system responds to avisitor request for a destination system, the formatting containedwithin the conditional formatting entry will be converted to css as wellsuch that the destination page will have elements with differentformatting.

Varying Output by Page Type

As part of serializing an object's properties into a stream for the CSStext definition that will be sent to the visitor, the destination systemmay take into account factors such as what kind of page type and whattype of visitor device characteristics are applicable to a given targetpage, according to an illustrative embodiment. For example, if the pageis of “report” type, the webifier may output a cell with a border as anhtml TD cell as follows “<td>Cell Text</td>” and some related CSS suchas “td border: {px solid black; }”. However, if the page is of type“edit details” and a cell falls within a range specified as cells thatcan be edited, webifier may instead output the same cell as “<td> <inputtype=text value=“Cell Text”/> </td>” and different CSS depending on thestyle of input controls desired.

Other types of output may be far more specialized. For example, a pagetype of calendar may, instead of trying to render the cells, render to astring format that can be accepted by a third-party widget such as acalendar control (FIG. 27 , within thumbnail), to be display ininteractive ways with features like browsing the months or switching toweekly or agenda views as the visitor specifies on the client-side. Thedestination system may also string render a sheet that has a name columnand GPS coordinate columns, to a comma delimited list that is acceptedby a third-party mapping application widget that interacts with athird-party server to render the map with the specified locations.

Data Validation

Sometimes spreadsheet tools include data validation capabilities. Forexample, a data validation rule can be specified in the spreadsheet toolwhere the cell should only allow whole numbers, only allow decimalnumbers, only allow numbers within a specified min and max range, onlyallow dates or times perhaps within a min and max range, limit the maxnumber of characters allowed, or limit the min number of charactersrequired, among others. A data validation can also be set to only allowthe cell to contain one of the values specified in a list. The list canbe provided during the data validation definition as a simple text listof values, or it can specify a reference to a range of cells on thespreadsheet where the tool would get the list of acceptable values fromand it can cause a dropdown control to appear within the spreadsheettool for that cell. The data validation can also be set to allow onlyvalues that would result in a typical spreadsheet formula return true.For example, for the cell B1, the formula could specify “=OR(B1>=0,AND(A1=0, A2<40))” in which case B1 can be a positive number or it canbe a negative if the cell A1 is zero and A2 is small number. Some toolsallow specifying an exception to allow blank values to pass thevalidation. The destination system can read all of the above datavalidation types and options that the designer has specified from thespreadsheet and spreadsheet cell definitions, according to anillustrative embodiment. The data validation could be on the celldefinition XML, or the data validation rules could be defined elsewhereas a group in the spreadsheet definition along with a list of cells therules are applied against. The destination system may extract andprocess that information from the spreadsheet definition. During inputsuch as an insert or edit of a value from the destination system thatcorresponds to the cell which had the data validation rule applied on itwithin the spreadsheet, the destination system would then evaluate thevisitor's input value as compared to these validation rules. Theevaluation could be done on the server or it could be done by passingthe rule to client-side JavaScript for example which would evaluate theinput of the user without requiring a request being sent to the server.If the data validation fails, a label or popup warning may be shown tothe visitor to give them the opportunity to correct the value. If thedata validation rule involved cell references from which to get the listof acceptable values or if the data validation rule involved a formulathat needs to evaluate to true, the system may dereference the othercell values required to evaluate the formula or that are required forthe system to know the list of acceptable values, which in turn wouldallow or disallow the visiting user's input. If the spreadsheetdefinition specifies a date based rule, the destination system maymodify the controls output onto an insert or edit form such that theuser has a popup calendar control to choose a date from and optionallytyping into the textbox control itself would be disabled to preventinvalid values from being specific to begin with rather than allowinginvalid values to be typed with a warning but not submitted to theserver.

To go beyond a spreadsheet styles of validation such as “A1=0”, thedestination system has additional options during the page creation wherea designer can add validations such as “Current User” or “Current Date”,that set the value of the cell automatically with information retrievedfrom the server. It is also possible to specify a map or GPS coordinatesrestriction, where the user could either input GPS coordinates or selectsomewhere on a map to generate the coordinates, and they would also bevalidated to be the correct GPS formatting for values. Deeper validationof GPS coordinates is also possible, by have min and max regionsspecified to the destination system that providing a bounding rectangle,by having polygons specified as the boundary, or pre-defined polygonslike “Europe”. Other convenience data validators are also available,even if they have the same effect as the traditional spreadsheet toolvalidators. For example, a validator that allows the designer tospecific a list of valid values (FIG. 80 ) is available and results in adropdown control being rendered on insert pages. A second example is adate validator that can limit what dates are selected (FIG. 79 ).

The destination system may enforce the data validation rules regardlessof the method of visitor input, including input methods such as inputforms (FIG. 93 ), CSV import pages (FIG. 87 ), or externally automatedwebifier API calls.

Concurrency and Formula Engine

Many visitors could log in to the destination system and requestread-only pages concurrently. For requests that involve editing, theserver may serialize all of the incoming requests or the requests' corecode that modifies the records, into a queue which would effectivelyseem concurrent given today's processing power, according to anillustrative embodiment. Applicable to many different page types, thedestination system may resolve the cell references and the formulas thatoriginated from the spreadsheet definition into simple text and numericvalues to be displayed to the user or recursively used in yet otherformulas in the spreadsheet definition or within other areas of thedestination system. The resolving of the formulas may be completed in anumber of ways. The same core processing engine or libraries as aspreadsheet tool may be reused or a custom parsing and formulaprocessing engine may be built to be embedded into the destinationsystem. In any case, the engine may have one or more callbacks thatresolve cell references based on row and column index values, or itcould be passed the spreadsheet definition or access to a database thatstores the cell definitions. The spreadsheet definition that is passedin may be a simplified or otherwise modified re-generated definitionthat is not the same as the original spreadsheet definition that waspassed in, or the original spreadsheet definition may be passed in. Incase of any collision between edits, the system may select or designatean accepted edit based on time (e.g., last man wins) or any otherdesired heuristics.

Workflows and Filtering Results

The webifier may allow some forms of workflow to be defined withvariations of the report page type and other page types, according to anillustrative embodiment. On a row-record sheet, a column could be addedby the designer intended to affect visitor permissions on a per-row, andtherefore per-record, basis, where the result of a particular column'scell formulas cause the destination server to include that row in theoutput results or not. For example, imagine an employee timesheetspreadsheet where column A includes the employee name and column Bincludes a number of hours, and a report page type with a source regionof that sheet. The added column C may have a formula, for each rowrepresenting a record, that resembles “=IsLoggedInUser(A1)” where A1would change to A2 for the second row and so forth. Although it wouldnot be able to resolve during design-time to show the designer a value,the destination system would evaluate the column of formulas when avisitor visits the timesheet listing report page. During iteration, thedestination system would skip over rendering of rows for the visitor ifthe employee specified in that row's column A was not the visitor. Rowswould continue to be rendered if it matched the visitor in column A. Thenet result is that an employee could visit a timesheet webpage, based ona spreadsheet definition, that would only show the rows of time recordsthat relate to that employee (FIG. 20 ). Similarly, if the sheet had acolumn specifying a supervisor, a supervisor timesheet overview pagemight list only the time records under that supervisor's purview.

If the page type were to be an edit page, the same evaluation offormulas may skip rows, thereby not only hiding information but alsopreventing input controls from being provided to prevent the user fromediting some rows while allowing the editing of other rows. Theunexpected effect of putting these components together is the ability toallow the user to define a workflow such as an employee seeing onlytheir own timesheet on a timesheet page and being able to change a“ready to submit” column to true for one or more records, having asupervisor see those records show up on a page that had formulas tolimit row viewing based on the “ready to submit” column, having asupervisor able to change an “approved” value for only the employeesthey are supervising, and finally having a manager see only approvedrecords and an aggregate total of approved time. In short, aspectsdescribed herein allow creation of custom and complex workflow thatpreviously required the assistance of an experienced software developer.

Buttons

For visitor convenience, metadata may be specified on a cell, forexample a cell comment using a spreadsheet tool's comment feature, thatincludes a tag that the destination system sees as a signal to changetext editing of values into a button control, according to anillustrative embodiment. For example, if the designer desired an“approved” value on each data record, it may be preferred by thedesigner that the visitor is able to click a button to indicate approvalof a record by changing the value of a cell from false to true, ratherthan presenting a textbox to the visitor to type the string “true” andwhere the visitor may change to put a “true” back to “false”. Thisresults in an easier to use system as well as aids in cases where achange to a value is one-directional (e.g., from false to true but thedesigner does not feel it valid for the record to ever change back tofalse).

For insert pages, even the destination system's default submit formbutton may have appearance and location defined by a cell with awebifier-defined or webifier understood formula function such as“=SubmitButton(Done, Green)” placed somewhere within the spreadsheettemplate. Drag and drop floating controls could also be used to positiona floating button if the spreadsheet tool supports it, which thedestination system would use as a basis for the position of a submitbutton on the destination pages. In this way, the destination system'sactual “hard-coded” interface, that is the interface not defined by aspreadsheet, is minimized on the destination pages.

Security+Indirect (Cascading) Filtering

The preventing of input can involve disabling or hiding of controls forpages where the designer has specified the source is the record sheet,or having the server refrain from sending the controls to the visitor atall. For security, the server may also confirm whether submitted inputsposted using a HTTP POST request are allowed based on the same logic,whether or not the controls were presented to the user, as the visitorcould be a malicious end-point rather than a normal browser, accordingto an illustrative embodiment. Other destination pages making use ofother template spreadsheets, intended to be populated with a variety ofrow-records, also evaluate allowance using the same logic. For example,if an invoice details report page with a Template Source of an invoicedetails template is being accessed by a destination system visitor, andit is being populated with invoice 205 on row 2 on the invoice recordlisting sheet, the destination system can check the invoice record sheetfor a column that specifies if row 2 has a formula that restricts accessto row 2. If so, the destination system would also restrict access tothe invoice details report page for invoice 205. In the case of nestedtemplates or where multiple source sheets are used in a single templateand other such complex scenarios, part of the destination page may bepopulated or rendered and part not, but the underlying method ofcascading remains.

Single Formula Rather than Entire Column

An alternative to adding a column with per-record formulas is to have aseparate single formula entered in a specified or referenced location onthe sheet or external to the sheet and stored within the destinationsystem, according to an illustrative embodiment. In this alternative,the destination system would then iterate through each row and apply theformula relative to the current row or record it is iterating on. Otherareas of webifier may make use of the same centralizing of formulasalternative.

For example, in the earlier example relating to permissions per-row,this document gave the example of a column C with formulas such as“=IsLoggedInUser(A1)” within C1, a formula such as “=IsLoggedInUser(A2)”for row 2, and so forth. The designer may then copy the formula down forall records, with the parameter to logged in user referring to column Afor each respective row. This functions, but can be cumbersome. Anexample of an alternative is to have “=IsLoggedInUser(A)”, or adifferent syntax rather than the usual spreadsheet formula syntax,defined separate to the sheet as an option during the creation of a pagethat refers to source records. The destination system may thenunderstand the “A” parameter, which refers to a column in general, to beequivalent to the “value in column A for the row representing the recordcurrently in question”. In other words, it may understand the formula tobe the equivalent of having the column C above. As another examplealternative, the “=IsLoggedInUser(A)” formula may be placed in a singlecell somewhere on the same sheet as the row records, perhaps to the farright of the row record information in cell “Z1”, and a field may existduring the page definition steps that specifies what single cellrepresents the formula for permissions per-row and may be set to “Z1” insuch an example.

Overlay Sheets

Sometimes a single record sheet is the basis of many destination systempages which have different permissions and different intended visitors.In such a case, several columns could be used to contain differentformulas to affect the permissions of the respective destination pages,according to an illustrative embodiment. As an alternative, thedestination system may add an Overlay Sheet to the spreadsheetdefinition. The Overlay Sheet may initially be a duplicate of therow-record sheet with all of the same values. It may be flagged by thedestination system as an Overlay Sheet, with metadata on the sheet'sspreadsheet definition, as a sheet intended to be based on therow-record sheet and intended to have page-specific modifications. Thedesigner may then add the column C to an Overlay Sheet, the destinationsystem may use that column C in much the same way as above, but it mayevaluate the formula as if it were added to the row-record sheetinstead, which allows it to work on the latest list of row records incase the list has changed since the Overlay Sheet was created. DifferentOverlay Sheets for different destination pages may have different columnC formulas. The Overlay Sheets may be updated whenever the row-recordsheet was changed, to keep the base content in sync but with only theintended new column C persisting as an example difference.

It is possible for Overlay Sheets to have no changes to the cellpositions or any new cells inserted, but rather include only visualformatting changes to the cells. For example, the overlay sheets maychange font colors, font sizes, or use a spreadsheet tool's traditional“hide columns” feature to also hide the respective content from thedestination pages. To avoid confusion with regular sheets, OverlaySheets may be indicated to the user as Overlays in a variety of ways.For example, the spreadsheet background can be set to a designatedcolor, e.g., light blue, throughout the sheet (FIG. 39 ).

Sometimes the template or overlay sheets can be “hidden sheets” if thespreadsheet tool supports hiding a sheet from the list of sheets, orotherwise the template sheets can be listed separately from other typesof sheets. When a designer is viewing a particular page, thoseadditional sheets would automatically be unhidden until viewing iscomplete.

Traditional Spreadsheet Tables

Rather than the destination system having a field during page creationto indicate that column C specifies row-based permissions, analternative is to have the spreadsheet definition imply this, accordingto an illustrative embodiment. Spreadsheets may have traditional“spreadsheet tables”, which typically comprise a region of cells and cancause the spreadsheet tools to be colorized, have filter and sortoptions on the header row, and other features to manage the display ofthe rows within a sheet when viewed within the traditional spreadsheettool (FIG. 74 ). The webifier can check for the presence of atraditional spreadsheet table in the spreadsheet definition of a sourcerow-record sheet used for a page or in the Overlay Sheet used for apage, and if the table is present the webifier may look at the table'spersisted state for filtering, sorting, and otherwise. If the designersorted the table's cells by column A, then the destination system willsort the output by column A as well. For the earlier example of choosingrow-based filtering permissions based on a formula in column C, thedesigner could set the table to filter on column “C=true” and thedestination system would filter the result output with the same logic.In this way, the creator of the page indicating that column C hasrow-based permissions that need to evaluate to true to see the row, isnot needed.

Applicable to any situation or method described herein where permissionsare filtering records, including the traditional tables method above asan example, the destination server can optionally render report pagesand other page types that depend on the row-record sheet with theaggregation functions within the spreadsheet formulas excluding thedisallowed records. With this method, per-record permissions would alsoaffect report pages with an aggregate graph for example. The designercould also disable this on a per-page basis, to have aggregate graphsunaffected by underlying row-record permissions, which effectively givesvisitors aggregate information but continues withholding granularper-record information.

Extraction of Updated Spreadsheet Definitions

After the destination system has already made use of the designer'sspreadsheet definition to provide visitors of the destination systemwith read only and/or input capable forms and content, and aftervisitors of the destination system have potentially modified or inputrecords, the destination system can provide the designer an updated,unified or multi-part, representation of all of the data and templates,in spreadsheet format fully compatible with spreadsheet tools, accordingto an illustrative embodiment. For convenience, this can be calledExtraction, as may be performed in step 215 (FIG. 2 ). Extraction can beprovided as a file download or by way of updating the spreadsheet tool,using the destination system Add-On or plugin that receives theinformation from the destination system and updates the sheets withinthe spreadsheet tool (FIG. 54 , “Download data” button). In most cases,the designer would then have received a spreadsheet that not only hasthe updated records, but also has the reports displaying actual databased on the record sheets, all without further involvement from thedestination system.

Extraction may be performed similarly to how the spreadsheet definitionfirst was put into the destination system, but in reverse. In oneexample, if the destination system persisted the spreadsheet definitionand did all modifications per-request, the destination system need onlydo the reverse of the designer's original upload a file; that is, offerthe xlsx data as a file for download by the browser. In another example,if the destination system persisted the spreadsheet definition afterunzipping the xlsx data and storing each contained unzipped file in thedatabase, then the system may reverse the steps by creating an unzippedfile for each record, zipping all of the data into an xlsx file, andthen offering the file as a download to the designer. As a thirdexample, if a database table was storing one record per cell but withoutchanging the schema of the cell content stored in the database, then thereverse may include iterating through all database entries andserializing the cell content into XML, and reintroducing per-sheetdefinitions that were stored in other database tables to generate theunzipped sheet file, and then proceeding with the steps noted in theother examples. As a fourth example, if the source spreadsheetdefinition was provided by way of web-service API calls fetching thedefinition, the reverse may include API calls delivering the newspreadsheet definition to replace the other one.

On some occasions, the designer, or other users, can perform extractionwhere the designer obtains one or more spreadsheet files or one or morespreadsheet sheets with one or more sheet templates populated with oneor more records. For example, this kind of extraction may result in aspreadsheet with 100 sheets and where each sheet is an invoice displayedin the form of one of the sheet templates. The steps and examples topackage the extraction for the designer may be similar, with somedifferences being that the destination system would need to follow thesteps of populating a template sheet, as it does in early stages ofgenerating a report page, but then redirecting the result to theextraction steps provided above rather than converting the cells intoother formats, and then iterating with other records populating thetemplate sheet.

The Add-On (plugin) may, via typical push notification or pollingmethods, provide real-time reloads and updates to the designer as thedestination system makes them available. Typically, this meansextraction steps are limited to being performed on whichever sheets orcells have changed due to visitors, and the Add-On updates only thosesheets or cells while leaving the remaining untouched. The Add-On maytake a hybrid approach of having real-time checks for updates butdownloading and saving any new spreadsheet definition as a local file onthe hard drive and then triggering the spreadsheet tool to open it, allwith minimal or no user involvement.

Continued Editing of Spreadsheet Definition

Whether extracted as a file or into the spreadsheet tool via the Add-Onor otherwise, the designer is now able to perform further modificationsto the template sheets and/or the record sheets as they did before theusing the destination system, according to an illustrative embodiment.In fact, the designer may have chosen to put into the destination systeman empty or nearly empty spreadsheet definition and then start buildingthe spreadsheet only after it is extracted, to leverage any destinationsystem features that are relevant at design-time. As a simple example,having the other designers aware for coordination purposes that aparticular new spreadsheet, indicating a particular new web-app, isbeing designed by that user due to the destination system displayingthis new web-app in the list of apps.

The destination system may have an option to lock or block all access,only have read access, or only have read and insert access, fromvisitors during the times that a designer has indicated they are editingthe spreadsheet or where the Add-On informs the destination systemserver that the designer is editing. Such blocking is typicallyrestricted to only sheets related to what the designer is currentlyediting, by determining if a visitor's page needs a sheet originallyfrom the same file as the sheet the designer is editing, or perhaps bydetermining if it's from the same file or there is the presence orabsence of any direct or recursively seeking for indirect referencesfrom the visitor's sheet to the designer's sheet being edited. Thisprevents unexpected collisions between changes by a visitor and changesby a designer, or from a visitor seeing a page derived from anin-progress and incomplete set of changes by a designer. Anothertechnique to help avoid those situations is that the designer indicatingthey are going to be making changes to the spreadsheet definition, againeither manually specifying or automatically via Add-On detecting it,causes the destination system to copy the representation it stores to astaging area, where the designer's changes only affect the staging areauntil the designer indicates they have completed a group of changes andare ready for the changes to go live, at which time the staging area iscopied back over the live web-app. During that time, either the liveweb-app is blocked entirely, is set to read-only, or is allowed toproceed but the changes the designer did while operating on the stagingarea are merged in, as a group, to the live app while retaining the liveapp's by the same methods that individual designer edits can be mergedin with a live web-app's records or a new spreadsheet definition can beuploaded and merged in with a live web-app's records.

The merging of the web-app's latest changes from visitors, with themerging of the designer's changes can employ a number of popular andcommon methods for merging data, as it can be done when both sides arein spreadsheet definition form. Commercially available libraries andtools may be used to identify the differences between spreadsheets andallow iterating through those differences to accept or deny each change,as well as libraries and tools that compare 3 spreadsheets: theoriginal, changed version A, and changed version B. They iterate throughand process changes that are not in conflict, and either rejectconflicts entirely or present the user the conflict information to makea decision as to which version wins.

One method of merging is to combine several other techniques, in a waythat is most conducive to expected uses of the webifier software. Forexample, a designer may be allowed to start making changes to thetemplate sheets and the destination system would not block visitorchanges to the record sheets. It is rarer that the destination systemhas visitors that change the template sheets although certainly possiblebecause the destination system can treat all sheets generically when thedesigner selects what sheets to report on, among other reasons.Nonetheless, the destination system may block by default only changes tothe template sheets, which it could know are exclusively template sheetsby iterating through how the designer has referenced that sheet duringthe creation of pages, whether it was referenced as a Template Sourcesheet or not. If the designer wanted to preview the effect of theirproposed changes, the destination system may automatically setup astaging area. If the designer was detected as modifying a record sheet,the webifier system may prompt the designer to block additional relatedparts of the web-app from concurrent input. In this approach, conflictresolution prompts to the designer can be avoided, and the designer isstill able to update the destination system's user interface viatemplate sheet changes and have the destination system not discard anyprevious or new records it contains.

In the case of inserts and some other types of edits, even insert typeof edits to the records is possible concurrently on the destinationsystem and the designer's tool without prompting for conflictresolution. A simple approach is to keep a copy of the originalspreadsheet definition that was sent to the designer at the start oftheir session or after they have indicated intent to do design work, andwhen uploading next to compare the designer's changes to the original todetermine which records are new and to cause the destination system toadd each of them, with short locking to allow the destination pages tocontinue operating and inserting while these newly inserted records fromthe designer are merged. In a similar fashion, a pre-designing originalcould be saved and compared to the designer's next upload to determinewhich records are missing and therefore intended to be deleted, ormodified and intending to be updated. Additionally, the same method ofcomparing to pre-designing originals could reveal adding or removingcolumns from the record sheets, and corresponding template sheet changesto match and indicating the designer's changes to the structure of theweb-app. In all cases, both the old records as well as newly visitoradded or visitor modified records on the destination system remainintact and the end result is a sensible merger between designer andvisitor changes to records, while simultaneously being able to haveupdated the interfaces the destination system sends visitors as well asthe structure of the records, e.g., in one step.

A challenge in allowing the continued editing of spreadsheet definitionsis that the designer may make changes to columns or rows such that anyreferences to ranges that the destination system stores may become outof date. One solution to this is having the Add-On watch for changes tothe location, the rows and column indices, of the spreadsheet cells thatare referenced, and to update the destination system accordingly inreal-time on an per event or per event-group basis. For example, if thedestination system has a range reference of “A5:A10” and a row isinserted at the top, then the webifier Add-On which is hooked into theappropriate event listeners, notifies the destination system to shiftany ranges below row 1 down, e.g., to “A6:A11” in this case.

To allow further flexibility to the designer to be able to modify thespreadsheet definition offline and on a computer that has no Add-Oninstalled (referred to as “Disconnected” designing), basically acomputer with only the unmodified third-party spreadsheet tool and acopy of the spreadsheet definition, that challenge is extended and theabove solution might not suffice. In this case the destination systemmay piggy back off of a spreadsheet's traditional named ranges featurebecause spreadsheet tools update named ranges based on designer changes,and such changes to the named ranges can be observed by the webifiersystem. This approach allows this desirable flexibility of modifyingspreadsheet definitions that affect the destination system whileDisconnected.

Notably, separate steps are not required for uploading records anduploading interface templates, they can occur with one step, by thedesigner or automatically, and with one spreadsheet definition beingprovided to the destination system. Of course, separate steps may alsobe used, if desired.

The designer may be notified, such as with a “Server Changes as of<date>” popup, that the destination system has received additionalchanges, from designers or visitors (FIG. 53 ). Common push notificationor polling of the destination system may be used to accomplish this.This allows the designer to reduce concurrent edit conflicts after thedesigner is done editing.

Named Ranges

When done through the Add-On, the webifier system may retrieve the NamedRanges from the spreadsheet (e.g., via a COM Interop library, asdescribed below) or from the destination system server, and pass thenames to the Add-On's web-based user interface using JavaScript,according to an illustrative embodiment. The webifier may create newNamed Ranges in order to capture the currently selected cells for dataSources when creating or editing destination pages, or in any otherfield or situation that the destination system requires a reference tothe spreadsheet cell(s) and that reference needs to be accessible to thedestination system for visitor requests to be processed. The names fortheses ranges may be “WebifierCustomRange” and appended with a randomlygenerated number from 0 to 2,147,483,647, for example. If a range withthat name already exists, a new random number may be generated until thecreated name is not attached to an existing range. Alternatively,incremental numbers may be used. If a custom range for the selectedcells already exists, the system may opt to use the existing name ratherthan create another one. Operations executed in the spreadsheet toolsuch as insert row or insert column expand the named range as per normalspreadsheet tool use. If a record is inserted via an Insert or CSVImport Page with a Named Range as its source, it will extend that Rangeto include the inserted records. If a Named Range referenced by anywebifier web page is deleted from the spreadsheet definition, when thesheet is uploaded the system will mark the affected Pages having invalidSources and they will be inaccessible until the Sources are edited orthe deleted Named Range is restored. Named Ranges may be used to definethe boundaries of Insert, Edit-Cells, Edit-Record, CSV Import, Report,Webpage, Calendar, and Details Report pages. Named Ranges may also beused to define header ranges for Insert, Edit-Cells, and Edit-Recordpages and to set the editable range for Edit-Cells and Edit-Record pages(FIG. 81 ). Using an Edit-Record page, named ranges may be automaticallydeleted if all cells in the range are deleted.

As an example, an insert page with automatically generated forminterface needs a source range that typically refers to a row-recordsheet. If the designer adds a column to the row-record sheet whileDisconnected but later uploads the updated definition, the destinationsystem will be able to see the updated Named Range that includes thenewly inserted column. In this example, the insert page would nowgenerate an additional label and html input control when that page sendsthe form to the visitor and visitors would, with no further actionneeded by the designer in this case, start generating new records thatinclude the new column of information.

Per-Cell Tracking

If the volume of cells to track is very high, named ranges can becombined with, or replaced entirely by, having an additional attribute,containing unique cell IDs generated by the destination system, insertedinto every cell of the extracted spreadsheet definition, according to anillustrative embodiment. Many spreadsheet tools will keep this attributein place as metadata even as cells are modified or moved or copied inthe spreadsheet tool, despite the spreadsheet tool having nounderstanding of the attribute's purpose. This affords much of the samebenefits of the named ranges but is not likely to be visible to thedesigner in the spreadsheet tool's user interface. The destinationsystem then extracts the unique ID in much the same way as other cellattributes, to obtain knowledge of what changes a user made whileDisconnected. That knowledge can then be used to update the referenceson the destination system to those cells, or alternatively, those uniquecell IDs could in some cases be sufficient as the method the destinationsystem uses to refer to cells rather than using the traditional row andcolumn indexing. Even ranges could be specified as UID:UID representingthe top-left corner and bottom-right corner of a range.

In similar fashion, other metadata can be stored in other parts of thespreadsheet definition that are hidden to the designer. For example,links to destination pages that require a sheet could be stored in anattribute within the XML definition of a sheet. If the spreadsheet toolsupports a schema where there are ranges that get automatically updatedlike named ranges do but where the ranges are not visible to the user,that feature may also replace named ranges.

Configuration Sheets for Destination System

An alternate approach to named ranges, referred to as “ConfigurationSheets” can also be substituted in the place of named ranges, accordingto an illustrative embodiment. The approach may include an additionalsheet named “DestinationSystemRanges”, potentially hidden if thespreadsheet tool supports hidden sheets, where the sheet has the 2columns of name and range. The destination system would then iteratethrough that sheet during uploading or at each visitor request, and findthe range that the destination system is seeking to resolve, by thevalue in the first column. For example, “Page1_SourceRange” may be oneof the names. The destination system may then obtain the cell's value orformula in the second column and use it in much the same way as thenamed range definition. The advantage of this approach is that the valuemay actually be a traditional spreadsheet formula and therefore even therange definition could be affected by other elements of the spreadsheetdefinition. This affords an unexpected amount of power and flexibility.For example, one could specify a formula where if an invoice totalis >$5000, then the details page should include an extra 5 rows in itspage source configuration that perhaps has additional fine print whichis desirable to show visitors but only for that invoice. At the sametime, the spreadsheet tool will automatically keep the ranges in sync inmuch the same way as named ranges. This allows a designer to effectivelymodify the configuration of custom reports, among other things, withminimal or no additional effort or training.

Data and metadata information that is required for the destinationsystem to serve destination pages, such as the page title, may be storedin a database separate from the spreadsheet definition. In much the sameway as a configuration sheet can replace named ranges, all data that isspecific to the destination system is able to be included in thespreadsheet definition and, importantly, editable by the designer in thefamiliar spreadsheet interface and approach. Another example is the pagetitle being defined in a Configuration Sheet, which would allow for pagetitles to be a result of any formulas a designer chooses. Page titleslike “Profit/Loss Report” can be “Profit Report” if a cell is >=$0 andthe title would be “Loss Report” if a cell is <=$0. Another example isthe entries into the notification system. Formulas such as“=IF(OtherSheet!A1>10, “Thomas”,“Patrick”)” could change the destinationof a notification based on a value within a record sheet. It could alsochange the time of delivery or any other notification attribute based onformulas the designer specifies and leveraging, in a somewhat cyclicalway, the underlying concept of this invention in order to have itselfconfigured by the designer. Some spreadsheet tools are able to acceptcell metadata where a cell is read-only when accessed within the tool.In such a case, Configuration Sheets may have some cells markedread-only to reduce the potential of accidental or incompatible designermodifications to the Configuration Sheet. For example, the ConfigurationSheet may have all cells read-only except the second column on theDestinationSystemRanges sheet described above.

Ultimately, implementing this approach consistently throughout, theentire definition of the destination system's web-app may be portableand configurable while Disconnected. At the same time, the entiredefinition of the web-app may be formula driven, arbitrarily definable,depend on other parts of the definition, and otherwise have unlimitedand unpredictable connections to the record sheets, template sheets,itself, function results like current dates, and otherwise.

External Supplementary Data: Files

Files may be uploaded to the destination system using theWEBIFIERINSERTFILE function (FIG. 7 ), according to an illustrativeembodiment. When a field containing the WEBIFIERINSERTFILE column isencountered while building the form for an Insert or Edit-Record page, aFile Upload control may be presented for that field (FIG. 62 ).Similarly, when editing a Cell that contains a WEBIFIERINSERTFILEfunction on an Edit-Cell page, the designer may have the choice ofediting the formula or uploading a new file. When WEBIFIERINSERTFILE isencountered in a spreadsheet tool with the Add-On, it may display a keythat can be used to retrieve information about the file using theWEBIFIERFILEATTRIBUTES function (FIG. 64 ).

If WEBIFIERINSERTFILE is encountered in a Report or Edit-Cell page, thefile may be displayed on the destination page. Visitors can view theseuploaded files in different ways, depending on the file type. If it isan image, it may be displayed within the cell (FIG. 63 ). If it is anaudio file, visitors can listen to it using the HTML5 audio player. Ifit is a video, visitors can watch it using the HTML5 video player. If itis any other type of file, a link is displayed that visitors can followto download it (FIG. 61 ).

Designers, from the destination system's admin pages, may be able toview and sort files on the system, and get details such as file keys,size, and which web-app each file belongs to. Files may also be viewedby web-app, to get an easy view of what files are associated with anweb-app. Permissions may also be applied to files, so only specificusers or groups of users can access a file. The destination system mayobtain these permissions based on the visitor having access to any cellthat references that set of files in the formula, or alternatively thedestination system may have a separate configuration interface thatlists the file groups, allows modification of their sharing settings,and specified a default set of permissions for new sets of files.

Uploaded files may be stored in an actual file directory, or a databasevirtual file listing, fashion and associated with the web-app to whichthe file was uploaded, in a directory named after the key that was orsupplied to or generated by the webifier. The type of file being storedmay be determined by the MIME content type of the file and recorded fordisplaying the file. Multiple files may be stored under the same key andcan be accessed by the index parameters of the Webifier file functions.

The WEBIFIERINSERTFILE function may allow zero, one, or two parametersconsisting of values or formulas (FIG. 7 ). The first parameter is anoptional string parameter which is a key that can later be used retrievethe upload files. If no key is specified, then a globally uniqueidentifier (GUID or guid) may be generated and used as the key. If thekey is specified, the user can also include an optional integerparameter that may be the index of the file under that key to be shown.If no index is specified, or the index is larger than the amount offiles, the function may show the most recently uploaded file whendisplayed. When a file is uploaded in an insert page, the newly insertedcell may be auto-filled with the function WEBIFIERINSERTFILE. The firstparameter in the formula may be the same key as the previous cell. Ifthe previous cell key parameter was a cell reference, it may be autoincremented to refer to the cell below. The second parameter may be thenew number of files so that when the cells is viewed on the website itmay display the newly uploaded file.

The WEBIFIERFILEATTRIBIUTES function may allow one, two or threeparameters consisting of values or formulas (FIG. 5 ). The firstparameter is the string key for the file; the second parameter, whichmay be optional (not shown), is the index of the file stored under thekey to get the attributes of; and the final parameter, also optional, isthe name or number of the attribute to be retrieved. “Name” or 0 for thename of the file, “Size” or 1 for the size of the file in KB,“DateUploaded” or 2 for the date the file was uploaded, and “Link” or 3for a URL to view the file on the website. If no index is specified, orthe index is larger than the amount of files, the function may get theattribute of the most recently uploaded file. If no attribute isspecified, the function may default to showing the name of the file.

All of the above variants and features of the external supplementaryfile system can apply for single file per cell variations or multiplefile and file folders per cell variations.

External Supplementary Data: Signatures

Signatures may be uploaded to the destination system using largely thesame methodology that the file based external supplementary datadescribed above uses for visitors uploading images. However, in thiscase of signatures being the form of external data, the file uploaddialogs and controls may be replaced with controls that allow a user toinput a signature. For example, a record sheet may have a column withformulas on every row record resembling“=WEBIFIERINSERTSIGNATURE(A2,‘thumbnail’)” where the column “A” has datathat can serve as a unique identifier, such as an employee name, and “2”in A2 changes to the appropriate row and where “presence” indicates thatthe cell shows a thumbnail of the signature, if available, or the text“n/a” if no signature is available yet. During design time, the Add-Onmay fetch such thumbnails for each record in order to display themwithin the cells. For visitors of a report page with the source is setto the entire record sheet, the signature thumbnails may appear besideevery record row displayed on the destination page. The thumbnails maybe clickable to open up a largely popup view of the captured signaturetogether with metadata such as the date and time the signature wascaptured. On an insert or edit destination page, the large popup viewmay also have a large canvas area whereby the user's movement of amouse, inkless pen on a digital tablet, or a finger on a touch-screenwould cause the canvas area to treat the movement as a pen and draw acorresponding line onto the canvas. There are commercially availablemodules for capturing motion such as for signatures into an image fileby way of such a canvas, commonly using JavaScript code to do so andprovide an html input form with image data to be uploaded to the serveron the form submission. Continuing this example, the destination systemmay store the image file representing the signature in the database, tobe retrieved on subsequent requests to view signature data for a recordon a report page. As an alternative to visual signatures, datarepresenting digital signatures may be obtained by client-sideJavaScript from one of numerous third-party issuers of PGP signedsignatures and a text summary or token artificial signature, using ahandwriting-like font, of such a digital signature may be displayed inthe place of a signature image. The visitor may be required to inputauthentication information, such as a username and password pair or athumbprint on a mobile device's thumb scanner using commerciallyavailable integration points for such hardware, in order for thethird-party issuer to issue a digital signature.

External Supplementary Data: Chat

The chat object feature allows a stream of chat discussions to beembedded or associated with one or more cells of a spreadsheet,according to an illustrative embodiment. The chat object allows visitorsto add messages to a cell that other visitors can then view, and to viewmessages left by others or themselves on a cell (FIG. 58 ). The chatobject represents a list of message objects, with each message objecttypically consisting of at least three parts: the message text, atimestamp indicating when the message was submitted and the username ofthe user who submitted the message. Each chat object may also have aunique identifier, i.e., an identifier distinct from other chat objects(e.g., FIG. 59 , “6ea6cc . . . ”. The identifier may be user-assigned orsystem-assigned. The identifier of a chat object may be used by thewebifier to refer to the chat object and to distinguish it from otherchat objects.

A chat object can be created by entering the insert-chat formulafunction, called WEBIFIERINSERTCHAT, which is a custom formula functiondefined by the webifier system (FIG. 6 ). To enter this function into acell, the user may be required to have permissions to set the formulafor that cell. This can be done in various ways, including through awebifier API call that allows it or through the spreadsheet tool withthe webifier Add-On installed.

To create a chat object in a cell, the designer may set the cell'sformula to the insert-chat function with no parameters (i.e.‘=WEBIFIERINSERTCHAT( )’), to the insert-chat function with the standardhyphen-separated string representation of a Globally Unique Identifier(GUID) as the only parameter (e.g.‘=WEBIFIERINSERTCHAT(“DC40FCA2-D72A-4AFD-80E4-76782B47D960”)’), or to aformula that that is evaluated to a unique identifier whether or not theidentified is a GUID or a string such as “Pleasant Solutions” whichwould represent a chat stream related to the record for that company.Several cells, on different sheets or the same sheet, may pass the sameparameter to WEBIFIERINSERTCHAT, allowing several destination pages orlocations within the pages to refer to the same shared chat stream.

When the user sets the insert-chat formula for a cell and saves it todestination system (e.g., by uploading the spreadsheet definitionchanges to the destination system if they are using a spreadsheet tooland the Add-On), the webifier performs several steps. First, it mayreplace every instance of the parameterless version of the insert-chatformula with the version containing a single GUID parameter. It maygenerate each instance of the GUID parameter using the Version 4 (IETFRFC 4122) algorithm, which means that the generated parameter is inpractice distinct from the GUID parameter of the insert-chat function inany other cell. Then it uploads the updated spreadsheet definition tothe destination system.

A chat object can be used by a visitor on a page that allows the visitorto view the cell in which the chat object is embedded (FIG. 57 ). Forexample, if the chat object is embedded in a cell on a particular sheetof a spreadsheet, and a visitor has access to a report page whose sourceis that sheet, then the visitor can interact with that chat streamthrough the destination pages.

When the destination system renders a page containing a cell whoseformula is the insert-chat function, it parses the GUID parameter ofthat function and checks its database to see whether there exists a chatobject whose unique identifier matches the parsed GUID. If there is nomatch, it creates a new chat object whose identifier is the parsed GUIDand whose list of message objects is empty, saves it to its database anduses this new chat object as the chat object for the cell. If there is amatch, it uses the matching chat object as the chat stream for the cell.In either case, the destination system displays inside the cell achat-bubble icon and the word ‘Chat’. If the visitor clicks the icon, itdisplays a modal window on that page showing the past message objectsfor that chat object (if any) in chronological order. Each past messageobject is shown with the full date and time it was posted, followed bythe username of the user who posted it, followed by the message text.Below the list of past messages, it shows a text box in which thevisitor can write a new message and a button to submit the new message.

If the visitor writes a new message in the text box below the list ofpast messages of a chat object (FIG. 58 ) and submits this message, thedestination system creates a new message object, sets its timestamp tothe system time, sets its username to the username of the visitor andsets its message text to the text submitted in the text box. It thenassociates the chat object with the message object and saves the messageobject and association information in the database. Finally, it returnsthe new message object to the client, which may use JavaScript todisplay the new message object below the list of past message objectsbut above the text box in the modal window and clears the text box, allwithout refreshing the page. The visitor can write further messages inthe text box, and submitting these further messages may trigger the samesteps again. If the visitor does not wish to enter any more messages,they may click anywhere outside the modal window, which may close themodal window and reveal the page behind it through which they accessedthe chat object.

Since the GUID parameter of the insert-chat formula is used as theunique identifier of the chat object, if the insert-chat formulas ofseveral different cells have the same GUID parameter, a message objectadded to the chat object embedded in one cell may show in the list ofmessage objects of the chat object embedded in the other cells, sincethe embedded chat objects of these cells are all the same chat object.

There are several External Supplementary Data systems possible. The twodescribed above are merely examples of the approach, and many of thefeatures described for one of the above examples are applicable to theother example.

According to another aspect, a video chat module may also oralternatively be used. A video chat object may be created by entering aninsert-video-chat formula function, called WEBIFIERVIDEOCHAT, which is acustom formula function defined by the webifier system. To enter thisfunction into a cell, the user may be required to have permissions toset the formula for that cell. This can be done in various ways,including through a webifier API call that allows it or through thespreadsheet tool with the webifier Add-On installed.

To create a video chat object in a cell, the designer may set the cell'sformula to the insert-video chat function with no parameters (e.g.,‘=WEBIFIERVIDEOCHAT( )’), to the insert-video-chat function with astandard hyphen-separated string representation of a Globally UniqueIdentifier (GUID) as the only parameter (e.g.‘=WEBIFIERVIDEOCHAT(“GC40FCA2-D73A-4AFD-80E4-76782B47D960”)’), or to aformula that that is evaluated to a unique identifier whether or not theidentified is a GUID or a string such as “Pleasant Solutions” whichwould represent a video chat related to the record for that company.Several cells, on different sheets or the same sheet, may pass the sameparameter to WEBIFIERVIDEOCHAT, allowing several destination pages orlocations within the pages to refer to the same video chat. In someaspects, a WEBIFIERVIDEOCHAT function may also require as input atdesign time a destination to connect to upon initiation of the videochat by the end user.

When generating a destination page, the webifier logic may then include,incorporate, or reference a video chat module on the web page which,when activated by a user, establishes a video chat between the end userand a predefined endpoint, e.g., the destination identified by thedesigner at design time. Video chat modules are readily available, e.g.,Drupal Video Chat, AVChat, Big Blue Button, etc.

Effects of Visitor Input

The following describes the process and effects of visitor input on thedestination system, in one illustrative use case scenario. When theInsert page form generated by the webifier system is submitted by avisitor, the destination system may first confirm that the Page ispublic or that the user has been give the appropriate permission to useit. If the user is permitted, the destination system will retrieve thespreadsheet definition associated with the App containing the Page andstart the insert process. If the user is not permitted to use the InsertPage, their submission may be discarded and the system may notify theuser.

Before inserting the record into the spreadsheet definition, date, timeand GPS coordinate data may be converted to string representations thatare appropriate for spreadsheet tools, and uploaded externalsupplementary files may be represented by a formula that references theWEBIFIERINSERTFILE function. When viewed in a spreadsheet tool, thefunction may return a key that can be used to retrieve the file from thedestination system at a later time with the WEBIFIERFILEATTRIBUTESfunction.

Once all the data is in an appropriate format to be saved, thedestination system will find the row or column immediately after thesource range or the next empty row or column if the entire worksheet isbeing used as the source and inserts the new data into the spreadsheet.At this point the spreadsheet definition validations may be evaluated,followed by validations that have been created in the destination systemseparately. If any of the validations fail, the user may be notified andgiven a chance to correct their submission. If any rows or columnscontaining Webifier formulas are present in the range, they may beauto-filled with the appropriate formula even if they have been hiddenby the Overlay Sheet.

After the data has been successfully inserted, all references to therange of cells constituting the data set which the new data was insertedinto will need to be updated. This may include the source of the Page ifis a named range, the sort and filter ranges saved in the Overlay Sheet,and any Chart Series that display the range of data that was extended.Once all the updates are complete, the modified spreadsheet may be savedback to the database along with any newly uploaded files. The ranges areconverted to the R1C1 string format so that they can be parsed to get anumerical representation of which rows and columns are currentlyincluded. The range values are then incremented by one row for a rowinsert or one column for a column insert, converted back to the R1C1string and saved back to the spreadsheet.

The destination system updates any Page thumbnails to be shown in thedestination system admin pages or within the Add-On, dependent on thedata from the Insert Page and Raises the Insert and Page Changed eventsused by the Notification system to send email alerts. If there is a‘Next Page’ configured for the Insert Page, the user will be redirectedto it.

Dynamic Page Selection

As described herein, multiple templates and multiple pages can exist forthe same records and for a similar or the same purpose, concurrently.The purpose can be any purpose or page type, including both read onlyand visitor input pages. The destination system may utilize informationfrom the browser or mobile client to help determine which template todisplay, according to an illustrative embodiment. For example, theinformation may include any number of device attributes or capabilitiessuch as screen size, screen resolution, OS version, browser brand andversion, manually specified preferences from the visitor as to which setof templates are preferred, and whether it is primarily a mouse,keyboard, or touch screen device. In the case of a web app, much of thisinformation can be obtained from the http “User Agent” header or byhaving JavaScript execute on the browser that transfers in-band orout-of-band to the destination server this information that is stored assession information temporarily by the web server. In the case of amobile app, the app can be designed to collect and transmit thisinformation upon first login authentication to the destination system.

The designer may specify a set of rules on the pages to specify whatcriteria each page requires to become accessible to the visitor, as wellas a fall-back default. The destination system may allow the designer togroup such pages as a way of indicating they have a common purpose, toachieve a single URL or page identifier and have requests to that singlelocation trigger destination system selection of which template tochoose. In the case of such grouping, the destination system would havethe ability for the designer to order the list along with the rules sothe system know the priority order of each page, with the last one beingdefault.

Gamification of Creating Sheet-Software

The building of complex software using sheets, as described herein, isfar easier for non-technical individuals than by other means.Nonetheless, the webifier system and/or Add-On (plugin) may watch forvarious actions or groups of actions on the part of a designer that canbe considered achievements, according to an illustrative embodiment. Ifthose actions meet various criteria, a visual popup may be displayedbriefly to the designer to indicate they have reached an achievement(FIG. 15 ). The popup may relay the value of what they have justcreated, such as “Your web-app is now ready to receive new records” or“You are done making your first web-app report”. The criteria caninclude a multitude of criteria such as being only one of the first 2times the designer has taken those actions, the designer not havingcompleted such an action in the past few months, a visitor has alsovisited the destination page related to the designer's actions, the userhas completed some actions in less time than the previous time suchsteps were timed, or the user has tried a different workflow ordifferent way of accomplishing something. The actions may involve notonly interactions with the destination system's or Add-On's userinterface, or that of visitor's associated with the destination pagesthe designer creates, but it may also be based on analysis of thedesigner's spreadsheets. For example, the gamification system may lookat whether the designer has created a traditional spreadsheet table,whether they used traditional conditional formatting on their templatesheets, or even whether they used basic aggregation functions in aformula like “=SUM(A1:A10)”.

The designer may have points, or several types of points, associatedwith their user account that get incremented based on theseachievements. Accumulating sufficient points over time may allow thedesigner to make use of new features within the destination system orAdd-On. Various actions or levels of points may trigger the destinationsystem's or Add-On's user interface to be modified to “advanced mode”.This may involve adding additional controls, removal of hint labels,changing controls for more complex ones such as a text box withvalidation rather than a dropdown, or changing its workflow by changingthe ordering of pages and location of buttons that the designer will bepresented such that it allows for more rapid sheet-software development.Reaching certain point levels may also change the licensing permissionrules surrounding the use of the webifier, for example to allow a greatnumber of visitors, either anonymous or with user accounts created, toaccess destination pages created by the designer.

Notifications

In the destination system, notification rules provide a facility wherebythe occurrence of certain events can trigger specified actions (FIG. 83), according to an illustrative embodiment. Regular users can set upnotifications for themselves. Administrative or designer users can setup notifications themselves and for users within their administrativedomain. To handle multiple events and/or perform multiple actions, auser may set up multiple notifications. The setup of each notificationrule requires the user to specify details about the event which shouldtrigger the notification and details about the action which should beperformed when the notification is triggered (FIG. 84 ). A notificationrule can be disabled while preserving all its other details so that whenit needs to be re-enabled, it can be without having to re-enter thesettings.

A notification can be triggered when an event is propagated to theserver, based on operations wholly inside the spreadsheet toolAdd-On/plugin or the web browser could trigger notification requestssent to the server, but might not until the action itself has beenpropagated or persisted to the server. Example events include when datais inserted into a page, when data on a page is edited, when theconfiguration of a page is changed, and when the configuration of an appis changed. For clarity, example events can be in the category ofvisitor high level-event triggered (insert page's submit button pushed),designer high level events (new page created), cell-event triggered (acell has changed), region-event triggered (at least one cell within agroup of cells has changed), sheet-event triggered, and can be bothdirect (a cell's formula changed) or indirect (the result of a cell'sformula has changed even though the cell formula itself has not). Whensuch actions occur, the action may raise a domain event corresponding tothat action.

The same domain events that may be used for notifications may also serveas the basis of a logging facility. Administrators may choose to logmore events than people are interested in being notified about, such asall CRUD (create, read, update, delete) operations concerning sheetdata, page configuration, or app configuration, and events such asrefused accesses. These logs may be sorted, filtered, or used forstatistical analysis. The destination system contains a notificationservice that handles these events.

The webifier services may filter the list of notification rules to theones that are currently enabled, whose settings specify that they shouldbe triggered by the type of event matching the action that occurred andthe particular page or app on which the action was performed. For eachsuch notification rule, the destination system carries out the actionsspecified by the rule. Possible actions include email action and thewebhook action (one notification rule may specify more than one action),as further described below.

To carry out the email action, the destination system may firstdetermine whether email should be sent for that rule. If it should not,it does not proceed with the rest of the email action steps. If an emailshould be sent, the system uses the template specified by the rule tobuild the various parts (subject, body, etc.) of an email message,substituting information about the event into any correspondingplaceholders that might be present. If the event specifies a destinationpage and the rule specifies that a PDF copy of the page should be sentwith the email, it may generate a PDF copy of the associated page andadd it as an attachment to the email message. Alternatively, thedestination page html may be embedded into the email, including anyinsert or edit forms that the page contains. The HTML may or may nothave modifications to account for its viewing within an HTML capableemail client, such as removal of page navigation menus, removal ofbackground images, removal of JavaScript references, or using morestandard and simplified controls for input fields rather thanspecialized ones, such as a standard text box rather than a popupcalendar to select a date. Submitting the embedded form would result inan http post request to the destination system. The URL of the postrequest may differ from the same destination page when rendered withoutembedding into an email, and may trigger different user authenticationwhereby login is not required because an authorization token is embeddedin the form and the http post, or different data validation rules whichmay take into account the input controls being more unpredictablefreeform input. The webifier then sends the message to the emailrecipients listed in the rule.

The content of the email can be specified in an email template form,which includes options for subject line, WYSIWYG editing of a rich texttemplate, a fallback for email systems that don't handle HTML, multiplerecipients (including cc and bcc), reply-to, and attachments (FIG. 85 ).Alternatively, commercially available email templating modules may beused. Additionally, the email content itself could be specified using asheet template where the destination system would output in HTML formatas it does for destination pages, but also would output in a fallback,simplified, text-only format for email clients that don't handle HTML.

To carry out the webhook action, the destination system may firstdetermine whether a webhook should be called for that rule. If it shouldnot, it does not proceed with the rest of the webhook action steps. Ifit should, it sends an HTTP POST request to the webhook URL specified bythe rule, with information about the event sent in the body of the POSTrequest. Webhook information may be, but is not limited to, JSON format.

All notification operations may go into a queue and may be processedasynchronously so that the event that triggered an action can carry on,and the user who triggered it can proceed to perform other functions onthe system, even if the email or webhook action fails or takes anextended time to complete. Because they are asynchronous, notificationscan also be stored for batch processing (for instance, a user may preferto receive a daily or weekly digest of all events, rather than acontinuous stream of notifications).

Mobile Considerations

The destination system is preferably responsive and fully compatibleacross all device platforms and integrates with several standard browserfeatures such as HTML and file transfer, according to an illustrativeembodiment. The destination system may also be integrated directly intoa native app through standard web-service API access methods to thedestination system, such that data contained within the destinationsystem is accessed by the user in a native app experience. Thepresentation of data in such a method is enabled by the destinationsystem through additional coding in a native SDK environment or otherdevelopment framework, for example Android Studio, Apple Xcode, Xamarin,or Cordova.

Further, the destination system may integrate with mobile devicesthrough the use of webviews for accessing functions and displaying data.This can access the destination pages in entirety within the app or canbe used to display smaller segments of data or access specificfunctions.

The destination system may execute fully interactive modules and othercode fragments (which may be scripted or compiled) that allow for all ofthe inclusion of destination system elements on other pages. Forexample, the destination system may support HTML iframe elements todisplay any of the page types on a 3rd party hosted website.

The destination system may also operate in a mode whereby file uploadsare accepted from a cloud-based file storage app that may or may not berunning on the same mobile device. This transfer may be accomplished bydirect file access or through an internet accessible API.

Although the descriptions throughout this document refer to web-pagesand browsers, they are largely unchanged in the case of mobileend-points such as above being a substitute for browser. Illustrativechanges may be summarized as first having an app installed on the mobiledevice which is designed and built to operate in a way fairly similar toa web browser, whether it is done largely as a browser for a page ormany requests getting many pieces that are put together with some userinterface elements that make it consistent for the mobile platform. Asecond change, the destination system server may in some cases generatea different output format rather than the CSS and HTML for the resultantdestination page, using one of the multitude of formats and methodstypical to the software development industry. Lastly, the mobile app mayhave a few hard-coded user interface elements, such as a menu of pages,that may be specific and consistent for the mobile platform, as opposedto an HTML menu. Such hard-coded user interface elements may be acombination of web-service API calls to fetch data lists and hard-codeduser interface code within the mobile app to process those data lists.

Defining Relationships

In some demanding usage scenarios, a designer may desire to have aprimary set of records in a record sheet as well as one or many“secondary records” in another sheet for each primary record, where thedesigner intends to identify secondary records as belonging to a primaryrecord by way of a “primary key”, as in the traditional databasesoftware sense, of the primary set of records, according to anillustrative embodiment. In short, the designer may intend to haverelationships expressed between the record sets in order to havetemplate sheets populated with not only primary record data but alsosecondary record data. For example, one record sheet may have columns“company ID” and “company name”, and one row having “1” and “PleasantSolutions” for values. A second record sheet may have columns “companyID” and “specialization”, and one row having “1” and “SoftwareDevelopment Consultants”. If the designer wishes to display a detailspage based on a template sheet that makes mention of both “PleasantSolutions” and “Software Development Consultants”, the webifier systemsupports such use, according to an illustrative embodiment.

For example, the destination system could request, in an advanced modeor section, that the designer select a column or row on one sheet andanother on another sheet, to indicate a primary key relationship betweenthem as a primary and secondary record set. Alternatively, thespecification of this relationship could be done in a ConfigurationSheet. Afterwards, the destination system may allow the designer tospecify in the source input controls not only one range or sheet, but alist of them; or the destination system can have the additional inputsautomatically implied based on the first range or sheet specified andthe primary key relationships that tie it to secondary sheets. Themethods described elsewhere for referencing record data from withintemplate sheets may at that point be applicable. The designer may use acell formula reference to either of the record sheets and, by parsingthat formula reference, it would be clear whether it was the primary orsecondary record set that the designer was intending to obtain datafrom. The destination system populating with the referenced data fromthe secondary record set would be done in the same fashion as populatingfrom the primary record set.

Library of “App Templates”

Entire App Templates including predesigned and/or preconfiguredspreadsheet definitions, with or without additional information from thedestination system such as the list of pages and their sharingpermissions, may be available from a community of designers to otherdesigner users to copy and use as a starting point for their own web-app(FIG. 22 ), according to an illustrative embodiment. These could belisted separately and searchable by purpose, category, industry, orsmart searching based on the page types within the app, column names onthe record sheets, keywords from any cell content, cell format such asdate fields being present, as well as association to what designers areusing that App Template web-app or what industry the employers ofdesigners are in.

The smart searching could also check if any other App Templates havebeen used from the same other designers, to associate the two designersas more similar. Alternatively, the destination system could compare aset of multiple spreadsheet definitions for one designer to that ofanother, based on presence of keywords from cell content or any of thesearch parameters noted above, to determine the level of similaritybetween the two designers. The search could then order the searchresults based on one or more of the above factors, frequency of thefactors occurring, and the importance of the factors. The system couldthen make use of common commercially known techniques and commerciallyavailable libraries for optimizing the search experience for the user.

Add-on Integration and Communication

The plugin or Add-On within the spreadsheet tool may communicate withthe destination system server and display its user interface in a numberof ways typical to the software development industry for a client-serverapplication model. For example, some of the diagrams illustrate theresult of the Add-On using web-service API calls the destination systemto obtain a predominantly HTML interface, a traditional webpage, andillustratively shows the web page in a frame that operates like anembedded browser window. This allows for many of the Add-On userinterface elements to be reused and to be largely consistent with theirrespective counter-parts on the destination system's admin pages fordesigners who do not have the Add-On installed. Some functionalitywithin the Add-On, such as the ability to use a mouse to select a rangeof cells, may be limited, removed, or altered in order to limit thedesigner to typing in ranges or, alternatively, may be performed on anembedded spreadsheet tool with the destination system admin pages. Forbrevity, attached figures representing Add-On user interface ordestination system admin pages, should be assumed to have theirrespective counter-parts even if not attached.

The integration of the Add-On to the spreadsheet tool may vary dependingon the spreadsheet tool into which the plugin is integrated. Forexample, integration with Excel may be done using Excel's COM Interoplibrary (development usage documentation publicly available athaps://msdn.microsoft.com/en-us/library/microsoft.office.interop.excel(v=office.15).aspx)or the JavaScript API for Office (development usage documentationpublicly available athttps://dev.office.com/docs/add-ins/develop/understanding-the-javascript-api-for-office).Cloud based spreadsheet tools such as Google Sheets may be integratedwith using web services, such as the Google Sheets API (developmentusage documentation publicly available athttps://developers.google.com/sheets/) which has readily accessible andunderstandable web-service API functions, such as retrieval of sheetranges using “spreadsheets.get(ranges, includeGridData)”.

If allowed by the spreadsheet tool's integration facilities, the systemcan integrate to the right click menu, for areas such as the cells orthe sheet tabs, to allow a modified process of the user indicating theirintent to perform an action related to the item such as adding a page.For example, instead of choosing to add a page and then specifying asource, the user could right click on a group of cells and select “addpage”, whereby the add page screen would already know the source beingintended and would not need to prompt the user for that information(FIG. 14 ).

Tight Integration with a Spreadsheet Tool

The webifier need not be a separate application from the spreadsheettool and it need not be limited to communication with the spreadsheettool via means made accessible to external applications. The webifiermay instead have a tight relationship whereby it may have a deeperand/or more back-end based integration and communication channel withthe spreadsheet tool. This also may be referred to herein as “tightintegration.”

According to some embodiments, the spreadsheet tool may be a web-basedspreadsheet system with a spreadsheet control that is embedded withinthe destination system server's pages and that allows editing thespreadsheet definition in any familiar manner of traditionalspreadsheets tools when the designer visits the destination system'sadmin pages. Alternatively, the reverse is possible, whereby webifiermay be a control that is embedded within a cloud spreadsheet tool's webinterface. In either case, the user interface presented to the designeris able to be even more tightly integrated and streamlined for thedesigner than that of a spreadsheet tool being a separate applicationwhich allows limited integration points. For example, navigating withthe browser would have a unified history of both spreadsheet anddestination system URLs, and the menus may be organized such that bothspreadsheet tool menu links and destination system menu links aregrouped in logical groups rather than being partly separated byapplication boundaries.

Whether or not the user interface is implemented to be more tightlyintegrated as noted above, the data transfer, synchronization, and otherback-end processes between the spreadsheet tool and the webifier may ormay not have tight integration as well. For example, rather thanweb-service API calls, webifier may use, in part or as a completereplacement for web-service API calls, function calls to a DLL libraryof the spreadsheet tool, or conversely, the spreadsheet tool may usecommon functions calls to a DLL library of webifier. This may provideperformance advantages for the webifier as well as allow integration tomake use of additional programming techniques, known to those skilled inthe art, such as shared memory access, low-level coordination objectssuch as mutexes and semaphores, accessing shared files, shared access tounderlying databases, and shared use of DLL libraries. Such flexibilitycan, for example, be advantageous for real-time change notificationsbetween the two components, where the two components refer to webifierand the spreadsheet tool.

Alternatively, the tight integration may allow webifier more directaccess to the underlying database data of the web-based spreadsheettool, or conversely, allowing the web-based spreadsheet tool more directaccess to the underlying database data of the webifier, or having anentirely shared database with a design schema designed specifically toallow the data of each component to reference the data of the otherdirectly such as by way of database foreign keys referenced from onecomponent's database table to another component's database table orhaving data for one component in a column on the same database table asa column containing the data from the other component. The direct accessmay provide significant performance advantages and may reduceimplementation complexity. For example, the tight integration may allowa single SQL query to confirm whether a destination page's record datahas changed, and where the query is evaluated efficiently within thedatabase. An example of such a query may involve joining a databasetable pertaining to the definition of a destination page's source data,to a database table which has a change log of the specific cells withina spreadsheet that have changed. Without this tight integration at thedatabase level, the webifier system might, for example, fetch largeamounts of cell data from a spreadsheet tool's web-service API which inturn might have the web-based spreadsheet tool fetch the data from itsdatabase; compare it cell data obtained earlier by fetching that fromthe webifier database, and map back the list of cells that have changedto all of the destination page's that make use of a cell reference tothat page.

Additionally, rather than the webifier and spreadsheet toolcommunicating in a schema common for spreadsheet definitions, the tightintegration may use an entirely different schema for database data,where the schema is more efficient for one or both components toprocess. For example, a typical spreadsheet definition may have XML dataorganized by sheets, with all the cells for that sheet nested withineach sheet's definition, and with the various cell attributes such asformatting and formulas and values nested within each cell's XMLdefinition. With tight integration at the database level, the examplemay be non-XML and may have database records that are normalized ratherthan nested, such as a database table having the columns “sheetId”,“rowId”, “columnId”, and “cellContents” where the ID's refer to otherdatabase tables. Further, the database schema need not even have cellcontents grouped together. The cell contents may instead be divided suchthat one database table has all of the cell formatting, a differentdatabase table has the cell formulas, and a third database table has thecell's cached values from evaluated the formulas. Further, the cellsmight not need to be organized in rows and columns because the databaseschema may have one or more database tables with a list of “units”,defined simply by a unique ID and the formula, and the schema may alsohave a separate table or tables that allow the units to be mapped backas rows and columns in select situations such as when the data is to bepresented to the designer as a familiar spreadsheet or the designer isinteracting with the data temporarily in spreadsheet form.

The tight integration may also allow the destination system andspreadsheet tool to not only reside on the same single server or groupof servers, but also to coordinate the most effective use of distributedcloud computing processes. For example, if an additional distributedserver needs to be spun up to support an increased load, the additionalserver may be delegated all designer and visitor requests relating to aspecific web-app and may be provided with an instance of both componentsalong with all data for that particular web-app. Such delegation acrossweb-app boundaries would allow the additional server to remain anefficient unit in regards to the web-app, with minimum transfer requiredto other servers. In contrast, without tight integration, it becomesmore complicated to ensure a particular server hosting a web-app and theassociated webifier instance, is the same server or even geographicallynear the server hosting the spreadsheet tool for the same web-app;therefore the communication between the components is either morecomplicated or is less efficient.

Overall, with tight integration, the spreadsheet tool and the webifierdo not need to be separate applications, the communication between thetwo does not need to be in the form of a spreadsheet definition northrough APIs, the storage of the data need not be in spreadsheetdefinition form, but the designer is nonetheless able to manipulate therecords and/or the UI templates while they are represented in the userinterface in spreadsheet form, and the visitor is still able to interactwith the data from destination pages not in spreadsheet form.

FIG. 3B shows an illustrative software architecture using tightintegration as described above. In FIG. 3B, the combined Tight System450 comprises the spreadsheet tool logic 452 and the webifier logic 453,both sharing a common memory 451 and both of which are integrated withcommunication mechanisms 410, shared libraries, and the like.

As further illustrated by FIG. 3B, a designer may create or make recordsheet and template sheet changes to one or more worksheets using abrowser 454 and the data changes are transferred 401 a as http postrequests with either a partial spreadsheet definition or as changeevents, to the Tight System's spreadsheet logic 452. The spreadsheetlogic 452 may convert the data to an alternate “Efficient Format” beforestoring 402 the designer's changes, or may store the data in a nativespreadsheet format. The designer may create or make changes todestination page configuration using the same or a different browser455, which get transferred 401 b to the webifier logic controller 453 ashttp post requests, and afterwards get stored 402 in memory 451.

Responsive to an http get request 403 b from a visitor's browser 456 tothe webifier logic 453 to provide a destination page, the webifier logic453 retrieves 404 the required data from memory 451. The webifier logicmay convert data into an html destination page by evaluated andreferencing values and formatting from the template sheet and evaluatingand referencing values from the record sheet identified based on thetemplate sheets. The destination page may be sent 405 b to the visitor'sbrowser 456. As FIG. 3B illustrates, the visitor sees a page having textlabels found only in the template sheet and not in the record sheet,text labels originating from RecordSheet!A1, values of “100” fromevaluating RecordSheet!C2, and html input controls defined by thetemplate sheet with values from the RecordSheet, RecordSheet!A2 for thecheckbox and RecordSheet!B2 for the textbox. FIG. 3B further illustratesthe ability of a visitor to check the checkbox and submit in the browser456 resulting in the browser sending an http post request 406 b to thewebifier logic controller 454. The webifier logic 453 processes the postrequest and updates the memory 451 with new data, optionally storing theEfficient Format or whatever format the system uses. If the designer'sbrowser 454 still has an active session, the spreadsheet logiccontroller 452 may obtain the updated data 408 from memory 451, oralternatively through integrated communication mechanisms 410, andconvert the data into one or more spreadsheet definitions or changeevents sufficient to update the spreadsheet definition presented in thedesigner browser 454, and sends 409 them to the designer's browser 409such that the designer's worksheet would then display “true” in cell A2.

As further illustrated by FIG. 3B, a web-service API call 403 m from avisitor's mobile device 457 running a mobile application (e.g., asopposed to a browser), may be a substitute for an http get request 403b. In this case, the webifier logic 453 may send 405 m the mobileapplication a response to the web-service API call, potentially in XMLformat, which is processed by the mobile application together withdevice or operating system specific design information, to generate aninterface for the visitor. As in this example, the mobile device's 457rendering of the destination page may differ from the visitor browser's456 rendering of the destination page in terms of having a differentlayout, different control types, and/or absence of some record data.FIG. 3B illustrates the ability of a visitor to also change the textboxvalue to true and clicking submit on the mobile device 457 resulting inthe mobile application sending a web-service API call 406 m to theWebifier logic controller 453. The Webifier logic 453 processes the datareceived from by the web-service and updates the memory 451 with newdata. The remaining steps may be similar to those resulting from thevisitor browser. As illustrated by FIG. 3B, the destination page may besent 405 m to the visitor's mobile device 457 running a mobileapplication (e.g., as opposed to a browser), or may be served to abrowser executing on the mobile device, but altering the appearance ofthe destination page based on one or more characteristics of the mobiledevice (e.g., screen size, hardware functionality, etc.).

Other Features

The system can use the same methods of template sheets as a “list itemtemplate”. For example, a page type of “list” could be created, wherethe inputs and outputs would be identical to the “details” page typeexcept that instead of requiring the user to select a row to view itsdetails, all row-records would be displayed one after another in a listform where each record on the list is displayed according to the itemtemplate. This, for example, allows for a row-record list to bedisplayed to visitors where several rows of information are needed perrecord but not enough to warrant a full details page or becausenavigating to a details page repeatedly is undesirable.

Throughout the interface, the designer may be presented with thumbnailsdepicting what the destination pages will look like to visitors. Thethumbnails may be inline in the user interface (e.g., as shown in FIG.28 ) and/or be depicted as a popup upon hover over portions of thescreen or specific controls (e.g., as shown in FIG. 11 ). As illustratedin many of the figures included herein (including at least FIGS. 28 and11 ), the thumbnails may depict the destination page result from thefigure's depicted spreadsheet definition.

Page types can have auto-refresh options, specified in a period of time,that would automatically have the client application or browser refreshthat destination page periodically for visitors (FIG. 48 ), according tosome aspects. Alternatively, the same approach for notification andlogging can be used to push notify open client sessions that a page orportion of a page has new information and either the notification wouldprovide the client the necessary information to update the page or theclient would send a new request to refresh the page. The use of eitherapproach may benefit a usage scenario of unmanned wall dashboards, suchas those powered by browsers that can visit a webpage and honor therefresh requests such that new information is always visible withoutviewer interactivity.

The destination system's permission system may also have rules to limitdesigner permissions, rather than just visitor or page permissions,according to some aspects. Designer permissions may include access typessuch as read-only, read and share, or read and share and update, (FIG.21 ) with a per-app, per-sheet, or per-page level of granularity. Forexample, read-only permissions on app ExampleApp would disallow thedesigner from modifying the spreadsheet definition for any sheets usedwithin ExampleApp, disallow changes to page configuration for pageswithin ExampleApp, but allow the designer to view the spreadsheetdefinitions as well as their underlying formulas and settings.

The destination system can support, as do many spreadsheet tools, cellformatting that make one or more cells a clickable hyperlink to aspecified URL, according to some aspects. This can be done using anattribute on the cell text that specifies the URL, where the presence ofthe URL may imply other formatting changes such as underlining and ablue color.

Illustrative Use-Case Scenario.

According to an illustrative use-case, a design may open a Windowsdesktop version of a spreadsheet application, e.g., MICROSOFT EXCEL,with the webifier Add-On already installed. The Add-On may include a“Sidebar” as the main Add-On user interface embedded into thespreadsheet application. The designer may be requested to login (FIG. 13). Successful login takes the designer to FIG. 12 with a list ofweb-apps previously made. The design may create a new spreadsheet filein the usual manner made available by the spreadsheet application andthen may click the upload arrow (upload to server) as seen in FIG. 12 .The designer may set a name for the app (FIG. 23 ) and the nearly emptyspreadsheet (in this example) gets sent to the server, becoming a nearlyempty web-app. The designer next sees an empty list of pages on FIG. 18, and clicks on the web-app action menu to see the menu in FIG. 69 orthe web-app tab's action menu to see the menu in FIG. 55 . The userclicks add page from that menu and goes to a form as in FIG. 51 that maydisplay properties common to all page types such as page “Title” and mayalso display a dropdown to choose a desired destination page type. Thedesigner will next see a primarily blank form requesting to define thepage type settings and configuration which, depending on the designer'schoice of page type, which may resemble FIG. 26 (API), 27 (calendar), 29(container), 33 (CSV import), 35 (details report), 38 (edit-cells), 41(edit-record), 43 (insert), 45 (link), 46 (PDF), 47 (report), 49 (tabscontainer). The designer may repeat this process to create as many pagesas desired, each incorporating one or more features described herein.

Any feature described above may be used with any particular aspect orembodiment of the invention. Many combinations, modifications, oralterations to the features of the above aspects and embodiments will bereadily apparent to the skilled person and are intended to form part ofthe invention. Any of the features described specifically relating toone embodiment or example may be used in any other embodiment orexample. In addition, although the subject matter has been described inlanguage specific to structural features and/or methodological acts, itis to be understood that the subject matter defined in the appendedclaims is not necessarily limited to the specific features or actsdescribed above. For example, the use of specific software applications,formulas and function names is not intended to be limiting ofalternative applications, formulas and/or function names that can beused, unless the claims recite such specificity. Rather, the specificfeatures and acts described above are disclosed as illustrative forms ofimplementing the claims.

The invention claimed is:
 1. A computer implemented method forgenerating an interactive web application comprising a display of datarecords from a spreadsheet, the method comprising: determining one ormore data sources within a spreadsheet, each data source having zero ormore data records, wherein the data sources comprise a first portion ofthe spreadsheet; determining at least one first user interface template,within the spreadsheet, corresponding to a first web page of theinteractive web application and comprising a layout or formatting fordata records to be included in the first web page, wherein the firstuser interface template is defined at least in part by one or more cellsof a second portion of the spreadsheet; generating the first web page ofthe interactive web application based on the first user interfacetemplate, wherein the first web page references at least one first datasource identified based on the first user interface template; generatingan input control, as part of the interactive web application, based onone or more rules defined in the first user interface template andconfigured to receive user input comprising an update to the content ofa data record of the first data source, wherein the rules are definedusing at least one formula native to a spreadsheet application thatgenerated the spreadsheet; responsive to a first request for apresentation of the first web page of the interactive web application,generating the presentation of the first web page including one or morefirst data records of the first data source, wherein the one or morefirst data records are identified based on and formatted according tothe first user interface template corresponding to the first web page;responsive to receiving user input via, the input control of theinteractive web application, comprising an update to the content of atleast one first data record included in the presentation of the firstweb page, determining whether the update to the content of the at leastone first data record satisfies the one or more rules; and responsive todetermining that the update to the content of the at least one firstdata record satisfies the one or more rules, updating at least onecorresponding data record of the spreadsheet.
 2. The method of claim 1,further comprising: generating a web data store comprising the datarecords of at least the first portion of the spreadsheet, whereingenerating the presentation of the first web page comprises retrievingthe one or more first data records from the generated web data store. 3.The method of claim 2, wherein the generated web data store comprisesthe spreadsheet.
 4. The method of claim 2, wherein the web data store isgenerated by extracting data records from at least the first portion ofthe spreadsheet.
 5. The method of claim 1, wherein the spreadsheetcomprises a plurality of worksheets, and wherein the first portion ofthe spreadsheet is on a different worksheet than the second portion ofthe spreadsheet.
 6. The method of claim 1, wherein the one or more rulescomprise a security permission rule configured to determine whether toprevent modification of a second data record within the spreadsheet by afirst user based on security permissions associated with the first user.7. The method of claim 1, wherein the one or more rules comprise aninput validation rule, the method further comprising: evaluating contentof the user input against the input validation rule, wherein updatingthe at least one data record of the spreadsheet is based on theevaluating.
 8. The method of claim 7, wherein the input validation ruleis associated with a particular data source.
 9. The method of claim 7,wherein the input validation rule is associated with the first web page.10. The method of claim 1, wherein the first user interface templatecomprises a data restriction rule, and wherein generating thepresentation of the first web page is based on selecting data recordsthat satisfy the data restriction rule.
 11. The method of claim 1,wherein the input control of the interactive web application is part ofthe first web page.
 12. An apparatus for generating an interactive webapplication comprising display of data records from a spreadsheet, theapparatus comprising: one or more processors; and memory storinginstructions that, when executed by the one or more processors, causethe apparatus to: determine one or more data sources within aspreadsheet, each data source having zero or more data records, whereinthe data sources comprise a first portion of the spreadsheet; determineat least one first user interface template, within the spreadsheet,corresponding to a first web page of the interactive web application andcomprising a layout or formatting for data records to be included in thefirst web page, wherein the first user interface template is defined atleast in part by one or more cells of a second portion of thespreadsheet; generate the first web page of the interactive webapplication based on the first user interface template, wherein thefirst web page references at least one first data source identifiedbased on the first user interface template; generate an input control,as part of the interactive web application, based on one or more rulesdefined in the first user interface template and configured to receiveuser input comprising an update to the content of a data record of thefirst data source, wherein the rules are defined using at least oneformula native to a spreadsheet application that generated thespreadsheet; responsive to a first request for a presentation of thefirst web page of the interactive web application, generate thepresentation of the first web page including one or more first datarecords of the first data source, wherein the one or more first datarecords are identified based on and formatted according to the firstuser interface template corresponding to the first web page; responsiveto receiving user input via the input control of the interactive webapplication, comprising an update to the content of at least one firstdata record included in the presentation of the first web page,determine whether the update to the content of the at least one firstdata record satisfies the one or more rules; and responsive todetermining that the update to the content of the at least one firstdata record satisfies the one or more rules, update at least onecorresponding data record of the spreadsheet.
 13. The apparatus of claim12, wherein the instructions further cause the apparatus to: generate aweb data store comprising the data records of at least the first portionof the spreadsheet, wherein the instructions cause the apparatus togenerate the presentation of the first web page by causing the apparatusto retrieve the one or more first data records from the generated webdata store.
 14. The apparatus of claim 12, wherein the spreadsheetcomprises a plurality of worksheets, and wherein the first portion ofthe spreadsheet is on a different worksheet than the second portion ofthe spreadsheet.
 15. The apparatus of claim 12, wherein the one or morerules comprise a security permission rule configured to determinewhether to prevent modification of a second data record within thespreadsheet by a first user based on security permissions associatedwith the first user.
 16. The apparatus of claim 12, wherein the one ormore rules comprise an input validation rule, wherein the instructionsfurther cause the apparatus to: evaluate content of the user inputagainst the input validation rule, wherein updating the at least onedata record of the spreadsheet is based on the evaluating.
 17. Theapparatus of claim 12, wherein the first user interface templatecomprises a data restriction rule, and wherein the instructions causethe apparatus to generate the presentation of the first web page basedon selecting data records that satisfy the data restriction rule.
 18. Anon-transitory computer-readable medium storing instructions that, whenexecuted by one or more processors, cause a computing device to performsteps comprising: determining one or more data sources within aspreadsheet, each data source having zero or more data records, whereinthe data sources comprise a first portion of the spreadsheet;determining at least one first user interface template, within thespreadsheet, corresponding to a first web page of the interactive webapplication and comprising a layout or formatting for data records to beincluded in the first web page, wherein the first user interfacetemplate is defined at least in part by one or more cells of a secondportion of the spreadsheet; generating the first web page of theinteractive web application based on the first user interface template,wherein the first web page references at least one first data sourceidentified based on the first user interface template; generating aninput control, as part of the interactive web application, based on oneor more rules defined in the first user interface template andconfigured to receive user input comprising an update to the content ofa data record of the first data source, wherein the rules are definedusing at least one formula native to a spreadsheet application thatgenerated the spreadsheet; responsive to a first request for apresentation of the first web page of the interactive web application,generating the presentation of the first web page including one or morefirst data records of the first data source, wherein the one or morefirst data records are identified based on and formatted according tothe first user interface template corresponding to the first web page;responsive to receiving user input via the input control of theinteractive web application, comprising an update to the content of atleast one first data record included in the presentation of the firstwebpage, determining whether the update to the content of the at leastone first data record satisfies the one or more rules; and responsive todetermining that the update to the content of the at least one firstdata record satisfies the one or more rules, updating at least onecorresponding data record of the spreadsheet.
 19. The computer-readablemedium of claim 18, wherein the instructions further cause the computingdevice to: generating a web data store comprising the data records of atleast the first portion of the spreadsheet, wherein generating thepresentation of the first web page comprises retrieving the one or morefirst data records from the generated web data store.
 20. Thecomputer-readable medium of claim 18, wherein the one or more rulescomprise an input validation rule, the method further comprising:evaluating content of the user input against the input validation rule,wherein updating the at least one data record of the spreadsheet isbased on the evaluating.
 21. A computer implemented method forgenerating an interactive web application comprising a display of datarecords from a spreadsheet, the method comprising: determining one ormore data sources within a spreadsheet, each data source having zero ormore data records, wherein the data sources comprise a first worksheetof the spreadsheet; determining at least one first user interfacetemplate corresponding to a first web page of the interactive webapplication and comprising a layout or formatting for data records to beincluded in the first web page, wherein the first user interfacetemplate is defined at least in part by one or more cells of a secondworksheet; generating the first web page of the interactive webapplication based on the first user interface template, wherein thefirst web page references at least one first data source identifiedbased on the first user interface template; generating an input control,as part of the interactive web application, based on one or more rulesdefined in the first user interface template and configured to receiveuser input comprising an update to the content of a data record of thefirst data source, wherein the rules are defined using at least oneformula native to a spreadsheet application that generated thespreadsheet; responsive to a first request for a presentation of thefirst web page of the interactive web application, generating thepresentation of the first web page including one or more first datarecords of the first data source, wherein the one or more first datarecords are identified based on and formatted according to the firstuser interface template corresponding to the first web page; responsiveto receiving user input via the input control of the interactive webapplication, comprising an update to the content of at least one firstdata record included in the presentation of the first webpage,determining whether the update to the content of the at least one firstdata record satisfies the one or more rules; and responsive todetermining that the update to the content of the at least one firstdata record satisfies the one or more rules, updating at least onecorresponding data record of the spreadsheet.
 22. The method of claim21, wherein the spreadsheet comprises the first worksheet and the secondworksheet.
 23. The method of claim 21, wherein the one or more rulescomprise a security permission rule configured to determine whether toprevent modification of a second data record within the spreadsheet by afirst user based on security permissions associated with the first user.24. The method of claim 21, wherein the one or more rules comprise aninput validation rule, the method further comprising: evaluating contentof the user input against the input validation rule, wherein updatingthe at least one data record of the spreadsheet is based on theevaluating.
 25. The method of claim 21, wherein the first user interfacetemplate comprises a data restriction rule, and wherein generating thepresentation of the first web page is based on selecting data recordsthat satisfy the data restriction rule.